衝突状況に応じて命令を再伝送するｒｆｉｄリーダー装置及びその制御方法

专利摘要:
衝突状況に応じて命令を再伝送するＲＦＩＤリーダー装置及びその制御方法であって、ＲＦＩＤリーダー装置は、一つ以上のタグに対して信号を送受信することが可能なＲＦ通信部からの送信信号に応じて、所定の受信時間の間に受信された受信信号のデータを分析し、受信信号の衝突発生の有無を確認し、受信信号データの分析結果に基づいて衝突タイプを診断する衝突診断部と、衝突診断部から受信した衝突発生の有無及び衝突タイプに基づいて、衝突状況に応じてタグにＲＦ通信部を介して命令を再伝送できるようにする衝突解決部とを含む。
公开号:JP2011514116A
申请号:JP2010550602
申请日:2009-03-12
公开日:2011-04-28
发明作者:オー、セウォン；ダーフィット、チシェ；チェ、ギルヤン；チェ、ジョンスク；パク、チャンウォン；ピョ、チョルシ；ヨーゼフ、プライスフーバー‐プフリュグル
申请人:エレクトロニクス アンド テレコミュニケーションズ リサーチ インスチチュートＥｌｅｃｔｒｏｎｉｃｓ Ａｎｄ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｒｅｓｅａｒｃｈ Ｉｎｓｔｉｔｕｔｅ；ツェーイーエスツェー、セミコンダクター、デザイン、ウント、コンサルティング、ゲゼルシャフト、ミット、ベシュレンクテル、ハフツングＣｉｓｃ Ｓｅｍｉｃｏｎｄｕｃｔｏｒ Ｄｅｓｉｇｎ ＋ Ｃｏｎｓｕｌｔｉｎｇ Ｇｍｂｈ；
IPC主号:H04B1-59

专利说明:

[0001] 本発明は、モバイルＲＦＩＤリーダー装置（ＲＦＩＤ ｉｎｔｅｒｒｏｇａｔｏｒ）及びその制御方法に係り、特に、衝突のタイプに基づいて状況に応じた命令再伝送（ｃｏｍｍａｎｄ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ）を遂行し、適応的に命令再伝送のための待機時間を設定することができるＲＦＩＤリーダー装置及びその制御方法に関する。]
[0002] 本発明は、知識経済部及び情報通信研究振興院のＩＴ源泉技術開発事業の一環として行われた研究から導き出されたものである［課題管理番号：２００８−Ｆ−０５２−０１、課題名：個別物品単位応用のための次世代ＲＦＩＤ技術開発］。]
背景技術

[0003] ＲＦＩＤ無線インターフェース仕様（例えば、ＩＳＯ／ＩＥＣ１８０００−６）は、ＲＦＩＤアーキテクチャ（例えば、ＲＦＩＤ Ｐｏｒｔａｌｓ）がよく揃うように開発されるにつれて、タグ間の干渉などによる通信エラーが非常に減ることになり、通信エラーの検出及び調整が容易になった。]
[0004] しかし、最近になってハンドヘルド（ｈａｎｄｈｅｌｄ）基盤のＲＦＩＤリーダーが大きな比重を占めることになって、モバイルアプリケーションにおいてＲＦＩＤテクノロジーの効果的な使用を保障することができる技術の必要性が台頭している。特に、大部分の固定シナリオ（ｓｔａｔｉｃ ｓｃｅｎａｒｉｏｓ）に比べると、アクティブモバイル装置の位置とローカル配列（ｌｏｃａｌ ａｒｒａｎｇｅｍｅｎｔ）、例えば、ターゲット対象との距離及びアンテナの方向などを根本的に予測することができなかった。すなわち、同一周波数チャネルでタグ検出と比較して、非同期で運営されるＲＦＩＤリーダーの数を決定するのが事実上難しいのである。]
[0005] 現在、互いに近接するＲＦＩＤリーダーは、配線によって連結され、これにより同期を合わせているが、このような同期化（ｈａｒｄ−ｗｉｒｅｄ ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ）は、モバイルアプリケーションに適用できない。もちろん、理論的には同期化を無線通信環境でも適用して使用することもできる。しかし、今までは、ＲＦＩＤリーダーの位置がわからないため、ＲＦＩＤヘンドヘルド装置の同期のために付加のチャネルを使用するしかなかった。]
[0006] 複数のＲＦＩＤリーダーが同一時間帯にアクティブ状態となることを防止するためのさらなる一つのメカニズムとしては、ヨーロッパで義務的に使用されているＬｉｓｔｅｎ Ｂｅｆｏｒｅ Ｔａｌｋ（ＬＢＴ）がある。しかし、ＬＢＴは、モバイルＲＦＩＤでは有効な方法でない。なぜならば、実際にＲＦＩＤリーダーの配列は非常に多様なので、有用な受信感度の基準値（ｔｈｒｅｓｈｏｌｄ）を決定することができないからである。]
[0007] その他にも、近接したＲＦＩＤリーダー間の意図しない衝突（ｃｏｌｌｉｓｉｏｎ）を克服するための方法としては、時分割多重化（ＴＤＭ、Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）及び周波数分割多重化（ＦＤＭ、Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）などがある。しかし、モバイルＲＦＩＤに時間的同期化がサポートされないか、ただ一つのチャネルが割り当てられるなら、これらのメカニズムはモバイルＲＦＩＤに適用することができない。言い換えれば、ＲＦＩＤリーダーとタグ通信は明らかでスペクトルにおいて区別できない。]
[0008] モバイル環境でＲＦＩＤリーダーを効果的に使用するためには、ＲＦＩＤリーダーは、モバイル環境で最近目立つようになった通信エラーに適応的ではなければならない。ところが、現在、ＩＳＯ／ＩＥＣ１８０００−６ Ｔｙｐｅ Ｃのような一般的なＲＦＩＤ無線インターフェース仕様を見れば、インベントリラウンドの間でフェイル（ｆａｉｌ）が発生した場合、リーダーが再伝送することができる命令のタイミング数あるいは命令を再伝送する条件に関して何の規制もしていない。また、命令の再伝送のためのランダム待機時間を選択する基準範囲に対して衝突回避と処理性能の間の合理的な折衷点を捜すための方法が必要である。]
[0009] 本発明の他の目的及び利点は下記の説明によって理解可能であり、本発明の実施例によってより明らかに分かるであろう。また、本発明の目的及び利点は特許請求の範囲に示す手段及びその組合せによって実現することができることが容易に分かるであろう。]
発明が解決しようとする課題

[0010] 本発明は、前記の従来技術の問題点を解決するためになされたもので、特にモバイルＲＦＩＤ環境で多様な衝突のタイプ及び状況に応じた命令再伝送を遂行し、適応的に命令再伝送のための最適の待機時間を設定することができるＲＦＩＤリーダー及びその制御方法を提供することを目的とする。]
課題を解決するための手段

[0011] 前記目的を達成するために、本発明による衝突状況に応じて命令を再伝送するＲＦＩＤリーダー装置は、一つ以上のタグに対して信号を送受信することが可能なＲＦ通信部からの送信信号に応じて、所定の受信時間の間に受信された受信信号のデータを分析し、受信信号の衝突発生の有無を確認し、受信信号データの分析結果に基づいて衝突タイプを診断する衝突診断部、及び衝突診断部から受信した衝突発生の有無及び衝突タイプに基づいて、衝突状況に応じてタグにＲＦ通信部を介して命令を再伝送できるようにする衝突解決部を含んでなり、衝突解決部は、衝突発生の有無と衝突タイプに基づいて命令を再伝送するか否かを判断する状況別命令再伝送部、及び命令の再伝送のためのランダム待機時間を計算するランダム待機時間計算部を含む。]
[0012] また、本発明による衝突診断部及び衝突解決部を含み、衝突状況に応じて命令を再伝送するＲＦＩＤリーダー装置の制御方法は、衝突診断部が、ＲＦ通信部からの送信信号に応じて、所定の受信時間の間に受信された受信信号のデータを分析し、受信信号の衝突発生の有無を確認し、受信信号データの分析結果に基づいて衝突タイプを診断する衝突診断段階、及び衝突解決部が、衝突発生の有無と衝突タイプに基づいて、衝突状況に応じてタグにＲＦ通信部を介して命令を再伝送できるようにする衝突解決段階を含み、衝突解決段階は、衝突発生の有無及び衝突タイプに基づいて命令を再伝送するか否かを判断する状況別命令再伝送段階、及び命令の再伝送のためのランダム待機時間を計算するランダム待機時間計算段階を含む。]
発明の効果

[0013] 本発明によれば、ＲＦＩＤリーダーがタグを読み取る過程で発生するすべてのタイプの衝突に対する識別が可能なので、衝突の発生原因を早く認知することができる利点がある。よって、衝突の発生原因に対処することができることになる。また、ＲＦＩＤリーダーを備えたモバイルアプリケーションで衝突が感知された場合、当該衝突タイプに応じて状況に応じた衝突制御を処理することで、もう始まったインベントリラウンド（ｉｎｖｅｎｔｏｒｙ ｒｏｕｎｄ）を成功裏に終了することができることになる。衝突のタイプによって状況に応じた命令再伝送を遂行することができ、適応的に命令再伝送のための待機時間を設定することができる。]
図面の簡単な説明

[0014] 本発明による衝突タイプ状況を示す例示図である。
本発明による衝突タイプ状況を示す例示図である。
本発明による衝突タイプ状況を示す例示図である。
本発明によるＲＦＩＤリーダーの構成を説明するブロック図である。
本発明によるＲＦＩＤリーダーの動作を説明する参照例示図である。
本発明によるＲＦＩＤリーダーの動作を説明する参照例示図である。
本発明によるＲＦＩＤリーダーの動作を説明する参照例示図である。
本発明によるＲＦＩＤリーダーの動作を説明する参照例示図である。
本発明によるＲＦＩＤリーダーの動作を説明する参照例示図である。
本発明によるＲＦＩＤリーダーの動作を説明する参照例示図である。
本発明によるＲＦＩＤリーダーの動作を説明する参照例示図である。
本発明によるＲＦＩＤリーダーに対する動作フローを示すフローチャートである。
本発明によるＲＦＩＤリーダーに対する動作フローを示すフローチャートである。
本発明によるＲＦＩＤリーダーに対する動作フローを示すフローチャートである。
本発明の実施例によって衝突解決部が衝突状況別に命令を再伝送する手順を示すフローチャートである。
図１５を参照して説明した衝突解決アルゴリズムの疑似コード表現である。
本発明の実施例によって各衝突状況に応じた衝突解決方法を説明する例示タイミング図である。
本発明の実施例によって各衝突状況に応じた衝突解決方法を説明する例示タイミング図である。
本発明の実施例によって各衝突状況に応じた衝突解決方法を説明する例示タイミング図である。
本発明の実施例による最小再伝送待機時間の意味を説明するタイミング図である。
本発明の実施例による最大再伝送待機時間の意味を説明するタイミング図である。
ＩＳＯ／ＩＥＣ１８０００−６ Ｔｙｐｅ Ｃ環境でのタイミングテーブルである。
待機時間パラメーターｃを現在衝突の比率によって動的に変更する手順を示すフローチャートである。
待機時間パラメーターｃを現在衝突の比率及びタイムアウトの比率によって動的に変更する手順を示すフローチャートである。] 図１５
実施例

[0015] 以下、本発明の理解のために、添付図面を参照して好適な実施例を提供する。下記の実施例は、本発明をより容易に理解するために提供するものであり、本実施例によって本発明が限定されるものではない。]
[0016] 本発明においては、極超短波（ｕｌｔｒａｈｉｇｈ ｆｒｅｑｕｅｎｃｙ、ＵＨＦ）帯域のＲＦＩＤ環境で動作するＲＦＩＤリーダー（Ｉｎｔｅｒｒｏｇａｔｏｒ）を装着した携帯電話で、タグが付いた商品や作品などの情報を照会するまたは購入するモバイルＲＦＩＤサービスにおいて、当該ＲＦＩＤリーダーと周辺のＲＦＩＤリーダーまたは周辺のタグとの衝突によって受信信号にエラーが発生した場合、発生した衝突を解決するために、エラーが発生した受信信号を分析して衝突の原因を識別し、衝突の状況に応じて命令を再伝送し、再伝送のための待機時間を適切に設定することができる装置及び方法を提示するものである。]
[0017] 本発明は、モバイルＲＦＩＤ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ ＩＤｅｎｔｉｆｉｃａｔｉｏｎ）のエアインターフェース仕様（ａｉｒ ｉｎｔｅｒｆａｃｅ ｓｐｅｃｉｆｉｃａｔｉｏｎ）に関するものであり、本発明によるシステムは、受動バックスキャッター（ｐａｓｓｉｖｅ ｂａｃｋｓｃａｔｔｅｒ）方式で動作するＩＴＦ（Ｉｎｔｅｒｒｏｇａｔｏｒ Ｔａｌｋｓ Ｆｉｒｓｔ）システムで、一つ以上のモバイルＲＦＩＤインテロゲーター（Ｉｎｔｅｒｒｏｇａｔｏｒ）と複数のタグを備える。以下ではＲＦＩＤインテロゲーターをＲＦＩＤリーダーとして説明し、特に他の説明があるかあるいははっきり他の用語に解釈されない限り、二つの用語は同一意味を持つ。]
[0018] 本発明によるＲＦＩＤリーダーは、チャネルセンシングをサポートしなくても良い。例えば、ＬＢＴ（Ｌｉｓｔｅｎ Ｂｅｆｏｒｅ Ｔａｌｋ）を具現化する必要がなく、リーダー間に衝突する危険を甘受して命令（ｃｏｍｍａｎｄ）を伝送する。また、ＴＤＭ（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）のための制御チャネルなどを利用してリーダー間に同期化を行わなくても良い。]
[0019] リーダーから提供するＲＦ信号によってタグに電源が供給され、アンテナの反射係数（ｒｅｆｌｅｃｔｉｏｎ ｃｏｅｆｆｉｃｉｅｎｔ）を変調してリーダーにデータをバックスキャッタリングすることで、リーダーの命令に反応する。タグの作動は手動モードであり、何のＲＦ通信も能動的に開始しないと仮定する。本発明は、モバイルＲＦＩＤ応用において衝突仲裁（ａｒｂｉｔｒａｔｉｏｎ）と衝突回避（ａｖｏｉｄａｎｃｅ）に関するものであり、衝突の影響を緩和させ、後続の（ｆｏｌｌｏｗ ｕｐ）衝突を回避するために使用することができるメカニズムに関するものである。]
[0020] 本発明において、具体的に説明されない部分は、ＩＳＯ／ＩＥＣ１８０００−６ Ｔｙｐｅ Ｃに規定された無線インターフェース仕様によって充分に理解することができ、必要によって他の無線インターフェース仕様も参酌して適用することができる。]
[0021] 以下、添付図面に基づいて本発明の実施例を説明すれば次の通りである。]
[0022] 図１〜図３は本発明の実施例によるネットワーク衝突状況を示すものである。] 図１ 図２ 図３
[0023] 本発明によるネットワーク衝突状況には複数のタグの間で発生する衝突である‘タグ対タグ衝突’（Ｔａｇ ｏｎ Ｔａｇ Ｃｏｌｌｉｓｉｏｎ）、複数のＲＦＩＤリーダーとタグの間で発生する衝突である‘マルチリーダー対タグ衝突’（Ｍｕｌｔｉｐｌｅ Ｉｎｔｅｒｒｏｇａｔｏｒｓ ｔｏ Ｔａｇ Ｃｏｌｌｉｓｉｏｎ）、当該ＲＦＩＤリーダーと周辺に位置する一つまたはそれ以上のＲＦＩＤリーダーの間で発生する衝突である‘リーダー対リーダー衝突’（Ｉｎｔｅｒｒｏｇａｔｏｒ ｔｏ Ｉｎｔｅｒｒｏｇａｔｏｒ Ｃｏｌｌｉｓｉｏｎ）の三つのタイプがある。]
[0024] まず、図１は本発明の一実施例によるタグ対タグ衝突状況を示すものである。] 図１
[0025] 図１を参照すれば、‘タグ対タグ衝突’状況は一つのＲＦＩＤリーダーであるＲ（１００）の読み取り範囲（ｒｅａｄ ｒａｎｇｅ）であるＡ内に複数のタグ２００が与えられた場合に発生することになる。図１の実施例においては、二つのタグであるＴ１（２００ａ）とＴ２（２００ｂ）が与えられた場合を例としたが、これに限定されるものではなく、それ以上のタグが与えられた場合にも適用可能である。] 図１
[0026] まず、Ｒ（１００）がインベントリ命令（ｉｎｖｅｎｔｏｒｙ ｃｏｍｍａｎｄ）を出力すれば、Ａ内に位置するＴ１（２００ａ）とＴ２（２００ｂ）がＲ（１００）のインベントリ命令に対して応答することになる。この際、Ｔ１（２００ａ）とＴ２（２００ｂ）が同時に応答する場合、Ｔ１（２００ａ）とＴ２（２００ｂ）による並列的な応答は相手タグの応答を邪魔することになる。これがまさに‘タグ対タグ衝突’である。]
[0027] ‘タグ対タグ衝突’が発生した場合、Ｒ（１００）はタグ対タグ衝突によってＴ１（２００ａ）及びＴ２（２００ｂ）から受信されたタグ応答をデコードするのにエラーが発生することになる。よって、インベントリ命令を出力したＲ（１００）は各タグの応答を正確に区分することができなくなる。このような‘タグ対タグ衝突’は無線インターフェース仕様（例えば、ＩＳＯ／ＩＥＣ１８０００−６ Ｔｙｐｅ Ｃ）に紹介されているタグ衝突調整アルゴリズム（ａｎｔｉ−ｃｏｌｌｉｓｉｏｎ ａｌｇｏｒｉｔｈｍ）によって解決可能である。以下で、タグ衝突調整は他の説明がなければタグ対タグ衝突を解決する従来のアルゴリズムを意味する。]
[0028] 以下の説明で、‘タグ対タグ衝突’は便宜上第１衝突として説明する。]
[0029] 一方、図２は本発明の一実施例によるマルチリーダー対タグ衝突状況を示すものである。] 図２
[0030] 図２を参照すれば、‘マルチリーダー対タグ衝突’状況は複数のＲＦＩＤリーダーによって発生される。図２の実施例では二つのＲＦＩＤリーダーであるＲ１（１００ａ）とＲ２（１００ｂ）が与えられた場合を例としたが、これに限定されるものではなく、それ以上のＲＦＩＤリーダーが与えられた場合にも適用可能であるのはいうまでもない。] 図２
[0031] 言い換えれば、Ｒ１（１００ａ）の読み取り範囲であるＡ１と、Ｒ２（１００ｂ）の読み取り範囲である‘Ａ２’が一部重なる状態で、Ａ１とＡ２が一部重なる範囲内に一つのタグであるＴ（２００）が位置する場合を例として説明する。]
[0032] この際、Ｒ１（１００ａ）とＲ２（１００ｂ）がＴ（２００）にインベントリ命令を出力する場合、Ｒ１（１００ａ）及びＲ２（１００ｂ）から出力されたインベントリ命令はＴ（２００）で衝突することができる。この場合、Ｔ（２００）はＲ１（１００ａ）及びＲ２（１００ｂ）からそれぞれ受信されたインベントリ命令をデコードする場合にエラーが発生することになる。]
[0033] 以下の説明で、‘マルチリーダー対タグ衝突’は便宜上第２衝突として説明する。]
[0034] 一方、図３は本発明の一実施例によるリーダー対リーダー衝突状況を示すものである。] 図３
[0035] 図３を参照すれば、‘リーダー対リーダー衝突’は二つのＲＦＩＤリーダーであるＲ１（１００ａ）とＲ２（１００ｂ）が存在し、Ｒ２（１００ｂ）の干渉範囲（ｉｎｔｅｒｆｅｒｅｎｃｅ ｒａｎｇｅ）であるＢ２がＲ１（１００ａ）の読み取り範囲であるＡ１と重なる場合に発生することになる。図３の実施例では二つのＲＦＩＤリーダーが与えられた場合を例としたが、これに限定されるものではなく、それ以上のＲＦＩＤリーダーが与えられた場合にも適用可能であるのはいうまでもない。ここで、‘リーダー対リーダー衝突’はＲ１（１００ａ）及びＲ２（１００ｂ）の読み取り範囲が重ならない状況でも発生することができるものである。] 図３
[0036] 例えば、Ｒ１（１００ａ）がＡ１内に位置するタグであるＴ（２００）にインベントリ命令を出力すれば、Ｔ（２００）はＲ１（１００ａ）のインベントリ命令に対する応答信号をＲ１（１００ａ）に伝送する。よって、Ｒ１（１００ａ）はＴ（２００）から受信された応答信号に応じた動作を遂行することになる。この際、Ａ１とＢ２が重なることになるので、Ｒ２（１００ｂ）から出力された所定の命令またはその他の信号とＲ１（１００ａ）に入力されるＴ（２００）の応答信号が衝突することになる。これがまさに‘リーダー対リーダー衝突’である。]
[0037] 従来、ＲＦＩＤリーダー間の衝突状況でＲ１（１００ａ）はＴ（２００）から受信された応答信号からエラーが検出された場合、これをタグ対タグ衝突と見誤ってそれに応じた衝突調整アルゴリズムを適用することで衝突を解決しようとした。]
[0038] また、‘リーダー対リーダー衝突’は二つのＲＦＩＤリーダーの読み取り範囲が重ならない状況でも発生することができるため、無線インターフェース仕様でも解決策が提示されていない。よって、モバイルＲＦＩＤ応用において‘リーダー対リーダー衝突’を検出するためのメカニズムが必要であった。よって、後述した本発明の実施例ではリーダー対リーダー衝突を検出するための実施例を説明した。]
[0039] 以下の説明で、‘リーダー対リーダー衝突’は便宜上第３衝突として説明する。]
[0040] 図４は本発明の一実施例によるＲＦＩＤリーダーの構成を説明するのに参照する図である。] 図４
[0041] 図４を参照すれば、本発明によるＲＦＩＤリーダーは、リーダー制御部１１０、リーダー送信部１２０、ＲＦ通信部１３０、リーダー受信部１４０、衝突制御部１６０及びタイマー１５０を含む。] 図４
[0042] リーダー制御部１１０は所定範囲内に位置する少なくとも一つのタグにインベントリ命令を出力し、インベントリ命令に応じて受信されたタグ応答を処理する。]
[0043] リーダー送信部１２０（モデム送信部）はリーダー制御部１１０のインベントリ命令をＲＦ通信部１３０に伝達する。ここで、リーダー送信部１２０はリーダー制御部１１０から出力されたインベントリ命令を変調してＲＦ通信部１３０に伝達する。]
[0044] ＲＦ通信部１３０はリーダー制御部１１０のインベントリ命令をリーダー送信部１２０から受け、所定範囲内に位置する少なくとも一つのタグに送出する。また、ＲＦ通信部１３０は、インベントリ命令を外部に送出した後、所定の受信時間の間に外部からの信号を受信する。この際、ＲＦ通信部１３０は所定の受信時間の間にすでに送出されたインベントリ命令に応じて読み取り範囲内のタグからタグ応答を受信する。もちろん、ＲＦ通信部１３０はタグ応答の外に他のＲＦＩＤリーダーの信号または何の信号も含まないノイズなどを受信することもできる。この際、ＲＦ通信部１３０は受信信号をリーダー受信部１４０に伝達する。]
[0045] リーダー受信部１４０（モデム受信部）はＲＦ通信部１３０からの受信信号をリーダー制御部１１０及び衝突制御部１６０に伝達する。この際、リーダー受信部１４０は受信信号データを衝突制御部１６０に伝達するようにする。]
[0046] 一方、リーダー受信部１４０はデコーダ（図示せず）を含む。この際、デコーダはＲＦ通信部１３０からの受信信号を復号化し、復号化された受信信号から有効プリアンブルを検出するようにする。リーダー受信部１４０はデコーダの有効プリアンブル検出結果に基づいて衝突制御部１６０に有効プリアンブル検出信号（ＶＰＤ、Ｖａｌｉｄ Ｐｒｅａｍｂｌｅ Ｄｅｔｅｃｔｉｏｎ）を出力するようにする。]
[0047] また、デコーダは復号化された受信信号からＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）エラーを検出するようにする。リーダー受信部１４０はデコーダのＣＲＣエラー検出結果に基づいて衝突制御部１６０にＣＲＣエラー検出信号を出力するようにする。]
[0048] 衝突制御部１６０は衝突診断部１６１及び衝突解決部１６５を含む。]
[0049] 衝突診断部１６１は、リーダー受信部１４０から入力された受信信号データを分析して受信信号に対する衝突発生の有無を確認し、受信信号データの分析結果に基づいて衝突タイプを診断するようにする。]
[0050] ここで、衝突診断部１６１は有効ビット検出モジュールであるＶＢＤ（Ｖａｌｉｄ Ｂｉｔ Ｄｅｔｅｃｔｉｏｎ）モジュール１６３を含む。ＶＢＤモジュール１６３は衝突診断部１６１のサブモジュールで、リーダー受信部１４０から入力された受信信号から有効ビットを検出する。言い換えれば、ＶＢＤモジュール１６３は、無線インターフェース仕様の許容誤差内で受信信号の立上りエッジ（ｒｉｓｉｎｇ ｅｄｇｅ）及び立下りエッジ（ｆａｌｌｉｎｇ ｅｄｇｅ）、つまり変調された副搬送波を検出することで有効な論理的な信号を検出する。この際、ＶＢＤモジュール１６３は有効ビット検出結果に基づいて有効ビット検出信号を出力する。]
[0051] 衝突診断部１６１は、有効ビット検出信号が感知（ｄｅｔｅｃｔ）された場合、有効ビット検出信号（ＶＢＤ）がポジティブ（ｐｏｓｉｔｉｖｅ）なものと判断する。言い換えれば、衝突診断部１６１は、有効ビット検出信号が感知された場合、ＶＢＤモジュール１６３から有効ビットが検出されたと判断する。]
[0052] 一方、衝突診断部１６１は、有効ビット検出信号が感知されない場合、有効ビット検出信号（ＶＢＤ）がネガティブ（ｎｅｇａｔｉｖｅ）なものと判断する。言い換えれば、衝突診断部１６１は、有効ビット検出信号が感知された場合、ＶＢＤモジュール１６３から有効ビットが検出されなかったと判断する。]
[0053] 衝突診断部１６１は、ＶＢＤモジュール１６３から出力された有効ビット検出信号に基づき、送信信号に応じたタグ応答信号が存在するかどうかを判断する。これにより、衝突診断部１６１は、受信信号が送信信号に応じたタグ応答であるか、それとも何の信号も含んでいない信号であるかなどを判断する。]
[0054] 一方、衝突診断部１６１はＲＦＩＤリーダーの衝突を感知するリーダー衝突感知モジュールであるＩＣＤ（Ｉｎｔｅｒｒｏｇａｔｏｒ Ｃｏｌｌｉｓｉｏｎ Ｄｅｔｅｃｔｉｏｎ）モジュール１６２をさらに含む。ＩＣＤモジュール１６２はＶＢＤモジュール１６３と同様に衝突診断部１６１のサブモジュールで、リーダー受信部１４０から入力された受信信号データを分析し、受信信号データに対する平均値を算出する。]
[0055] また、ＩＣＤモジュール１６２は受信信号データから算出された平均値と登録された基準レベルの比較結果に基づいてＲＦＩＤリーダーの衝突を感知する。この際、ＩＣＤモジュール１６２はＲＦＩＤリーダーの衝突が感知された場合、リーダー衝突検出信号（ＩＣＤ）を出力する。]
[0056] 例えば、ＩＣＤモジュール１６２は、受信信号データから算出された平均値が基準レベル以上の場合、ＲＦＩＤリーダーが衝突したと感知する。一方、ＩＣＤモジュール１６２は、受信信号データから算出された平均値が基準レベル未満の場合、ＲＦＩＤリーダーが衝突しなかったと感知する。]
[0057] これに対する具体的な実施例は図６及び図７を参照するようにする。] 図６ 図７
[0058] 衝突診断部１６１は、ＩＣＤモジュール１６２から出力されたリーダー衝突検出信号に基づいて当該ＲＦＩＤリーダーと周辺ＲＦＩＤリーダーの衝突、つまり第３衝突の発生有無を確認することが可能である。]
[0059] 言い換えれば、衝突診断部１６１は、リーダー衝突検出信号が感知された場合、リーダー衝突検出信号（ＩＣＤ）がポジティブ（ｐｏｓｉｔｉｖｅ）なものと判断する。言い換えれば、衝突診断部１６１は、リーダー衝突検出信号が感知された場合、ＩＣＤモジュール１６２からＲＦＩＤリーダーの衝突が検出されたと判断する。この際、衝突診断部１６１は受信信号に対して第３衝突が発生したと診断する。]
[0060] 一方、衝突診断部１６１は、リーダー衝突検出信号が感知されない場合、リーダー衝突検出信号（ＩＣＤ）がネガティブ（ｎｅｇａｔｉｖｅ）なものと判断する。言い換えれば、衝突診断部１６１は、有効ビット検出信号が感知された場合、ＶＢＤモジュール１６３から有効ビットが検出されなかったと判断する。この際、衝突診断部１６１は受信信号に対して第３衝突は発生しなかったと診断する。]
[0061] また、衝突診断部１６１は、ＩＣＤモジュール１６２から出力されたリーダー衝突検出信号がネガティブ（ｎｅｇａｔｉｖｅ）なものと判断されれば、ＶＢＤモジュール１６３から出力された有効ビット検出信号に基づいて複数の周辺タグ間の衝突、つまり第１衝突の発生有無を確認する。また、衝突診断部１６１はＶＢＤモジュール１６３から出力された有効ビット検出信号に基づいて複数のＲＦＩＤリーダーと送信信号を受信したタグ間の衝突、つまり第２衝突の発生有無を確認する。]
[0062] 衝突診断部１６１は、ＶＢＤモジュール１６３から有効ビット検出信号（ＶＢＤ）がポジティブなものと判断されれば、受信信号に対して第１衝突が発生したと診断する。一方、衝突診断部１６１は、ＶＢＤモジュール１６３から有効ビット検出信号（ＶＢＤ）がネガティブなものと判断されれば、受信信号に対して第２衝突が発生したと診断する。]
[0063] 衝突診断部１６１は、デコーダから有効プリアンブルが検出された場合、リーダー受信部１４０から有効プリアンブル検出信号を受信する。また、衝突診断部１６１は、デコーダからＣＲＣエラーが検出された場合、リーダー受信部１４０からＣＲＣエラー検出信号を受信する。ここで、衝突診断部１６１は、リーダー受信部１４０から出力された有効プリアンブル検出信号とＣＲＣエラー検出信号に基づいて受信信号に対する衝突タイプを診断するようにする。]
[0064] すなわち、衝突診断部１６１は、ＩＣＤモジュール１６２から出力されたリーダー衝突検出信号とＶＢＤモジュール１６３から出力された有効ビット検出信号に基づいて、第１衝突、第２衝突、及び第３衝突に対する衝突タイプを診断することができる。これに対する実施例は［表１］を参照する。]
[0065] また、衝突診断部１６１は、ＩＣＤモジュール１６２から出力されたリーダー衝突検出信号及びＶＢＤモジュール１６３から出力された有効ビット検出信号に加え、リーダー受信部１４０から入力された有効プリアンブル検出信号とＣＲＣエラー検出信号をさらに参照してより細密な衝突タイプを診断することができることになる。これに対する実施例はつぎの［表２］を参照する。]
[0066] 衝突診断部１６１は、前記のような条件を満足する場合、衝突状況と判断し、第１衝突、第２衝突、及び第３衝突の中でいずれか一つの衝突タイプと診断し、前記のような条件を満足しない場合、受信信号に衝突が発生しないと判断する。]
[0067] この際、衝突診断部１６１は、衝突診断結果を衝突解決部１６５に伝達するようにする。ここで、衝突診断結果は衝突発生の有無を含み、衝突が発生した場合、衝突タイプ情報を含む。]
[0068] 衝突解決部１６５は、衝突診断部１６１から印加された衝突診断結果に応じた動作を遂行するようにする。言い換えれば、衝突解決部１６５は、衝突診断部１６１によって衝突が発生しなかったと診断されれば、これをリーダー制御部１１０に通報するようにする。]
[0069] また、衝突解決部１６５は、タグ対タグ衝突、マルチリーダー対タグ衝突及びリーダー対リーダー衝突の中でいずれか一つの衝突が発生した場合、各衝突タイプに応じた衝突解決アルゴリズム（ｃｏｌｌｉｓｉｏｎ ｒｅｓｏｌｕｔｉｏｎ ａｌｇｏｒｉｔｈｍ）を遂行することで衝突問題を解決するようにする。衝突解決部１６５は、衝突発生の有無と衝突タイプに基づいて命令を再伝送するか否かを判断する状況別命令再伝送部１６５１、及び命令の再伝送のためのランダム待機時間を計算するランダム待機時間計算部１６５２を備え、衝突解決部１６５の具体的な動作については衝突診断部１６１が衝突を診断する動作を説明した後に説明する。]
[0070] 図５は本発明による衝突制御部の動作説明するのに参照する図である。] 図５
[0071] 図５を参照すれば、衝突診断部１６１は、リーダー受信部１４０から受信信号データ（Ｉ１）を受ける。この際、衝突診断部１６１のＶＢＤモジュール１６３は、受信信号データから有効ビットを検出して有効ビット検出信号（Ｉ１１）を出力する。また、衝突診断部１６１のＩＣＤモジュール１６２は受信信号データからリーダー衝突を検出してリーダー衝突検出信号（Ｉ１２）を出力する。] 図５
[0072] 一方、衝突診断部１６１は、リーダー受信部１４０から有効プリアンブル検出信号（Ｉ２）とＣＲＣエラー検出信号（Ｉ３）を受ける。]
[0073] また、衝突診断部１６１はタイマー１５０から時間情報（Ｉ４）を受ける。この際、衝突診断部１６１は、タイマー１５０から提供された時間情報（Ｉ４）に基づき、送信信号に対して設定された受信時間がタイムアウトされるまでの時間をカウントする。また、衝突診断部１６１は、送信信号に応じたタグ応答が受信されるまでの時間をカウントする。]
[0074] 衝突診断部１６１は、有効ビット検出信号（Ｉ１１）、リーダー衝突検出信号（Ｉ１２）、有効プリアンブル検出信号（Ｉ２）、及びＣＲＣエラー検出信号（Ｉ３）情報を利用して受信信号に対する衝突発生の有無及び発生した衝突タイプを診断するようにする。]
[0075] この際、衝突診断部１６１は衝突診断結果を衝突解決部１６５に出力することになる。ここで、衝突診断結果は衝突なし（Ｎｏ ｃｏｌｌｉｓｉｏｎ ｄｅｔｅｃｔｅｄ）、第１衝突、第２衝突、及び第３衝突に対する情報を含む。もちろん、衝突診断結果は診断された衝突を解決するための衝突制御命令を含むことができる。]
[0076] 図６及び図７は衝突診断部のＩＣＤモジュールでＩＣＤを検出する動作説明に参照する図である。] 図６ 図７
[0077] ＩＣＤモジュール１６２でＩＣＤ信号を検出するに先立ち、衝突診断部１６１はＩＣＤモジュール１６２のパラメーター値を調整する。]
[0078] 例えば、衝突診断部１６１は、リンク周波数（ＬＦ、Ｌｉｎｋ Ｆｒｅｑｕｅｎｃｙ）、データ速度（ｄａｔａ ｒａｔｅ）、信号変調タイプなどから移動平均フィルター（ＭＡＦ、Ｍｏｖｉｎｇ Ａｖｅｒａｇｅ Ｆｉｌｔｅｒ）のウィンドウ（またはタブ）の大きさを決定する。ここで、受信信号データに対する平均値を算出する区間であるウィンドウの大きさは手動または自動で調整することができる。]
[0079] 衝突診断部１６１は、送信信号に対するタグ応答を受信するためのタグ応答周期を決定する。ここで、タグ応答周期は、リンク周波数、データ速度及び変調タイプなどから決定される。]
[0080] また、衝突診断部１６１は、ＩＣＤモジュール１６２でリーダー信号を検出するために基準となる基準レベル（Ｔｈｒｅｓｈｏｌｄ_ｌｅｖｅｌ）を決定する。ここで、基準レベルは、信号変調タイプ、リンク周波数（ＬＦ）、データ速度の中で少なくとも一つ以上によって決定される。]
[0081] 前記のように、衝突診断部１６１によってＩＣＤモジュール１６２のパラメーター値が決定された後、ＩＣＤモジュール１６２はリーダー受信部１４０から入力される受信信号のシンボルデータによってＲＦＩＤリーダーの衝突有無を検査するようにする。]
[0082] 図６は本発明によるＩＣＤモジュールの構成を示す例示図、図７はＩＣＤモジュールでの信号流れを示す図である。図６及び図７を参照すれば、ＩＣＤモジュール１６２は平均計算部１６２ａと比較器１６２ｂを含む。] 図６ 図７
[0083] 平均計算部１６２ａは、リーダー受信部１４０から入力された受信信号データを入力値として受けて入力された受信信号データに対する平均値を算出する。この際、平均計算部１６２ａは移動平均フィルター（Ｍｏｖｉｎｇ Ａｖｅｒａｇｅ Ｆｉｌｔｅｒ、ＭＡＦ）を含む。すなわち、平均計算部１６２ａは、移動平均フィルター（ＭＡＦ）に受信信号データが入力されれば、移動平均フィルターのウィンドウに入力された各フィルター値（Ｓ１、Ｓ２、Ｓ３、．．．、Ｓｎ）を合わせて平均値を算出するようにする。すなわち、移動平均フィルターのウィンドウに入力された区間の平均値を算出するようにする。受信信号のデータが移動平均フィルターのウィンドウに追加入力される場合、追加入力された受信信号データに対する平均値を算出するようにする。]
[0084] 比較器１６２ｂは、平均計算部１６２ａから算出された平均値と登録された基準レベル（ｔｈｒｅｓｈｏｌｄ_ｌｅｖｅｌ）を比較し、リーダー衝突検出信号を出力するようにする。この際、比較器１６２ｂは、平均計算部１６２ａから算出された平均値の中で基準レベル以上の値に対してリーダー衝突検出信号を出力するようにする。この際、衝突診断部１６０は当該リーダー衝突検出信号、つまりＩＣＤがポジティブ（ｐｏｓｉｔｉｖｅ）状態のものとみなす。]
[0085] すなわち、衝突診断部１６１は、リーダー衝突検出信号においてＩＣＤが‘ｐｏｓｉｔｉｖｅ’状態の場合、当該ＲＦＩＤリーダーと周辺ＲＦＩＤリーダーの間で第３衝突が発生したとみなす。この際、ＩＣＤ値は衝突関係にあるリーダーを知らせるものである。]
[0086] 言い換えれば、図７の（ａ）のように受信信号のシンボルデータが入力された場合、衝突診断部１６０によって決定されたタグ応答時間（Ｔ１）の間に入力された受信信号データに対する移動平均フィルター区間の平均値は図７の（ｂ）のようである。ここで、衝突診断部１６０は送信信号を送出した後に所定の受信時間の間にＲＦ通信部１３０から受信信号を受信する。本実施例ではタグ応答時間（Ｔ１）の間に受信信号を受信することにする。] 図７
[0087] この際、ＩＣＤモジュール１６２は（ｂ）の平均値のうち、先に衝突診断部１６１によって決定された基準レベル（Ｔｈｒｅｓｈｏｌｄ_ｌｅｖｅｌ）と比較するようにする。その結果、ＩＣＤモジュール１６２は図７の（ｃ）のようにリーダー衝突検出信号を衝突診断部１６１に出力するようにする。すなわち、タグ応答時間である‘Ｔ１’の間の平均値の中で基準レベルを超える領域である‘Ｔ２’でＩＣＤが‘ｐｏｓｉｔｉｖｅ’状態となることを確認することができる。] 図７
[0088] したがって、衝突診断部１６１は、ＩＣＤモジュール１６２から出力されたリーダー衝突検出信号に基づいて受信信号で第３衝突が発生したと判断する。]
[0089] 図８はＶＢＤモジュールで有効ビットを検出する実施例を示すものである。特に、Ｍｉｌｌｅｒ−４でエンコードされた受信信号から有効ビットを検出する例を示すものである。] 図８
[0090] ここで、ＶＢＤモジュール１６３によって有効ビットが検出された場合、ＶＢＤは‘ｐｏｓｉｔｉｖｅ’となり、有効ビットが検出されない場合には、ＶＢＤが‘ｎｅｇａｔｉｖｅ’となる。ＶＢＤモジュール１６３は有効ビット検出結果に基づいて有効ビット検出信号を出力する。これにより、衝突診断部１６１はＶＢＤモジュール１６３から出力された有効ビット検出信号に基づいて受信信号の衝突タイプを診断するようにする。]
[0091] したがって、衝突診断部１６１は先に獲得された情報、つまりリーダー衝突検出信号、有効ビット検出信号、有効プリアンブル検出信号、及びＣＲＣエラー検出信号から図９〜図１１の衝突タイプを診断することができることになる。] 図１０ 図１１ 図９
[0092] まず、図９は第１衝突状況を示すもので、詳しくはＲＦＩＤリーダー（Ｒ）とタグ１（Ｔ１）及びタグ２（Ｔ２）の間で送受信される命令及び応答信号を示すものである。ただし、他のＲＦＩＤリーダーからの干渉はない状態とみなす。] 図９
[0093] まず、ＲＦＩＤリーダー（Ｒ）がタグ１（Ｔ１）及びタグ２（Ｔ２）に命令を伝送すれば、タグ１（Ｔ１）及びタグ２（Ｔ２）はそれぞれ応答１と応答２をＲＦＩＤリーダー（Ｒ）に伝送する。この際、同一応答スロット（ｒｅｓｐｏｎｓｅ ｓｌｏｔ）で二つ以上のタグ応答、つまり応答１と応答２の一部がオーバーラップされることにより衝突が発生することになる。]
[0094] この際、衝突診断部１６１は、つぎの＜条件Ａ＞または＜条件Ｂ＞を満足する場合、第１衝突が発生したと診断する。]
[0095] ＜条件Ａ＞ １）有効プリアンブル検出（ＶＰＤ ｉｓ ｐｏｓｉｔｉｖｅ）。
２）ＣＲＣエラー検出。
３）有効ビット検出（ＶＢＤ ｉｓ ｐｏｓｉｔｉｖｅ）。
４）検出されたリーダー衝突なし（ＩＣＤｉｓ ｎｅｇａｔｉｖｅ）。]
[0096] ＜条件Ｂ＞ １）検出された有効プリアンブルなし（ＶＰＤ ｉｓ ｎｅｇａｔｉｖｅ）。
２）有効ビット検出（ＶＢＤ ｉｓ ｐｏｓｉｔｉｖｅ）。
３）検出されたリーダー衝突なし（ＩＣＤｉｓ ｎｅｇａｔｉｖｅ）。]
[0097] 言い換えれば、＜条件Ａ＞のように、有効プリアンブル検出信号からＶＰＤが‘ｐｏｓｉｔｉｖｅ’であり、ＣＲＣエラーが検出され、有効ビット検出信号からＶＢＤが‘ｐｏｓｉｔｉｖｅ’で、リーダー衝突検出信号からＩＣＤが‘ｎｅｇａｔｉｖｅ’であることを満足する場合、衝突診断部１６１は受信信号で第１衝突が発生したと診断する。一方、＜条件Ｂ＞のように、ＶＰＤが‘ｎｅｇａｔｉｖｅ’で、ＶＢＤが‘ｐｏｓｉｔｉｖｅ’で、ＩＣＤが‘ｎｅｇａｔｉｖｅ’であることを満足する場合、衝突診断部１６１は受信信号で第１衝突が発生したと診断する。]
[0098] したがって、衝突診断部１６１は＜条件Ａ＞及び＜条件Ｂ＞のいずれか一つを満足する場合、第１衝突情報を含む衝突診断結果を衝突解決部１６５に出力するようにする。]
[0099] 図１０は第２衝突状況を示すもので、詳しくはリーダー１及びリーダー２と一つのタグの間で送受信される命令及び応答信号を示すものである。] 図１０
[0100] 図１０に示すように、ＲＦＩＤリーダー１（Ｒ１）とＲＦＩＤリーダー２（Ｒ２）はタグ（Ｔ）に命令を出力する。この際、ＲＦＩＤリーダー１（Ｒ１）とＲＦＩＤリーダー２（Ｒ２）からそれぞれ出力された命令１と命令２がオーバーラップされた場合、衝突が発生することになる。この場合、タグは有効なＲＦＩＤリーダーの命令を検出することができないので、タグ応答は出力されなくなる。よって、ＲＦ通信部１３０は、送信信号を送出した後に他のＲＦＩＤリーダーの信号またはノイズなどを受信することになる。] 図１０
[0101] この際、衝突診断部１６１はつぎの＜条件Ｃ＞を満足する場合、第２衝突が発生したと診断する。]
[0102] ＜条件Ｃ＞ １）検出された有効プリアンブルなし（ＶＰＤ ｉｓ ｎｅｇａｔｉｖｅ）。
２）検出された有効ビットなし（ＶＢＤ ｉｓ ｎｅｇａｔｉｖｅ）。
３）検出されたリーダー衝突なし（ＩＣＤｉｓ ｎｅｇａｔｉｖｅ）。]
[0103] ＜条件Ｃ＞のように、ＶＰＤが‘ｎｅｇａｔｉｖｅ’で、ＶＢＤが‘ｎｅｇａｔｉｖｅ’で、ＩＣＤが‘ｎｅｇａｔｉｖｅ’であることを満足する場合、衝突診断部１６１は受信信号で第２衝突が発生したと診断する。]
[0104] したがって、衝突診断部１６１は、＜条件Ｃ＞を満足する場合、第２衝突情報を含む衝突診断結果を衝突解決部１６５に出力するようにする。]
[0105] 図１１は第３衝突状況を示すもので、詳しくはリーダー１及びリーダー２と一つのタグの間で送受信される命令及び応答信号を示すものである。] 図１１
[0106] まず、ＲＦＩＤリーダー１（Ｒ１）がタグ（Ｔ）に命令１を伝送すれば、タグ（Ｔ）はＲＦＩＤリーダー１（Ｒ１）の命令１に応じて応答１をＲＦＩＤリーダー１（Ｒ１）に伝送する。一方、ＲＦＩＤリーダー２（Ｒ２）は他のタグに命令２を伝送する。]
[0107] この際、ＲＦＩＤリーダー１（Ｒ１）の読み取り範囲とＲＦＩＤリーダー２（Ｒ２）の干渉範囲が重なるので、タグ（Ｔ）の応答１とＲＦＩＤリーダー２（Ｒ２）の命令２が互いにオーバーラップされることによって衝突が発生することになる。図１１の（ａ）は応答１の一部が命令２とオーバーラップされた場合を示すものであり、図１１の（ｂ）は応答１の全体が命令２とオーバーラップされた場合を示すものである。ここで、図１１の（ａ）及び（ｂ）は伝送されるプロトコルデータユニット（ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）のアクチュアルタイミング（ａｃｔｕａｌ ｔｉｍｉｎｇ）によって発生することになる。] 図１１
[0108] この際、衝突診断部１６１は、つぎの＜条件Ｄ＞または＜条件Ｅ＞を満足する場合、第３衝突が発生したと診断する。]
[0109] ＜条件Ｄ＞ １）有効プリアンブル検出（ＶＰＤ ｉｓ ｐｏｓｉｔｉｖｅ）。
２）ＣＲＣエラー検出。
３）リーダー衝突検出（ＩＣＤｉｓ ｐｏｓｉｔｉｖｅ）。]
[0110] ＜条件Ｅ＞ １）検出された有効プリアンブルなし（ＶＰＤ ｉｓ ｎｅｇａｔｉｖｅ）。
２）リーダー衝突検出（ＩＣＤｉｓ ｐｏｓｉｔｉｖｅ）。]
[0111] まず、＜条件Ｄ＞のように、ＶＰＤが‘ｐｏｓｉｔｉｖｅ’で、ＣＲＣエラーが検出され、ＩＣＤが‘ｐｏｓｉｔｉｖｅ’である場合、衝突診断部１６１は受信信号で第３衝突が発生したと診断する。一方、＜条件Ｅ＞のように、ＶＰＤが‘ｎｅｇａｔｉｖｅ’で、ＩＣＤが‘ｐｏｓｉｔｉｖｅ’である場合、衝突診断部１６１は受信信号で第３衝突が発生したと診断する。]
[0112] ここで、ＩＣＤは基本的に当該ＲＦＩＤリーダーと周辺ＲＦＩＤリーダー間の衝突を検出する信号なので、ただ第３衝突でだけ‘ｐｏｓｉｔｉｖｅ’状態となる。よって、衝突診断部１６１は、＜条件Ｄ＞または＜条件Ｅ＞を満足する場合、第３衝突情報を含む衝突診断結果を衝突解決部１６５に出力するようにする。]
[0113] その後、衝突解決部１６５は衝突診断部１６１によって診断された衝突を解決し、発生する衝突を最小化するため、発生した衝突タイプに応じた衝突解決アルゴリズムを遂行するようにする。衝突解決部１６５は、衝突解決アルゴリズムを遂行した後、遂行結果をリーダー制御部１１０に伝達する。]
[0114] 前記のように構成された本発明の動作を説明すれば次のようである。]
[0115] 図１２〜図１４は本発明の一実施例によるＲＦＩＤリーダーの動作フローを示すフローチャートである。] 図１２ 図１３ 図１４
[0116] まず、図１２はＲＦＩＤリーダーの全体動作フローを示すものである。図１２を参照すれば、ＲＦＩＤリーダーは、周辺のタグに送信信号、つまりインベントリ命令を伝送する（Ｓ５００）。当該ＲＦＩＤリーダーのＲＦ通信部１３０は、‘Ｓ５００’過程で伝送された送信信号に応じて、所定の受信時間の間に外部から信号を受信する（Ｓ５１０）。この際、ＲＦ通信部１３０は、当該ＲＦＩＤリーダーの読み取り範囲内にある少なくとも一つのタグからタグ応答信号を受信することになる。もちろん、‘Ｓ５１０’過程で受信される信号はタグ応答信号の外に他のＲＦＩＤリーダーの信号またはノイズを含むこともできる。] 図１２
[0117] ＲＦＩＤリーダーの衝突診断部１６１は、‘Ｓ５１０’過程で受信された受信信号のデータを分析し（Ｓ５２０）、受信信号の衝突発生の有無及び衝突タイプを診断するようにする（Ｓ５３０）。]
[0118] ‘Ｓ５３０’過程での診断結果、当該受信信号が正常タグ応答信号であると判断されれば（Ｓ５５０）、衝突診断部１６１はこれを知らせる信号を衝突解決部１６５に出力するようにする。この際、衝突解決部１６５は、衝突診断部１６１の衝突診断結果をリーダー制御部１１０に伝達することにより、リーダー制御部１１０がタグ応答によって応じた動作を遂行するようにする（Ｓ５７０）。]
[0119] ‘Ｓ５３０’過程での診断結果、当該受信信号で衝突が発生したと判断されれば（Ｓ５５０）、衝突診断部１６１は、衝突解決部１６５に衝突診断結果を出力するようにする。この際、衝突解決部１６５は、衝突診断部１６１の衝突診断結果に基づき、当該衝突タイプに応じた衝突解決アルゴリズムを遂行するようにする（Ｓ５６０）。]
[0120] 図１３及び図１４は図１２の‘Ｓ５３０’過程の詳細過程を示すもので、図１３は簡単な動作フローを示すものであり、図１４は図１３をより細分化した動作フローを示すものである。] 図１２ 図１３ 図１４
[0121] まず、図１３を参照すれば、衝突診断部１６１は、リーダー受信部１４０から入力された受信信号のデータを分析結果、ＩＣＤモジュール１６２から出力されたリーダー衝突検出信号及びＶＢＤモジュール１６３から出力された有効ビット検出信号に基づき、受信信号で発生した衝突タイプを診断する。] 図１３
[0122] ＩＣＤモジュール１６２から出力されたリーダー衝突検出信号に基づいて‘ＩＣＤ＝ｐｏｓｉｔｉｖｅ’の場合（Ｓ５３１）、衝突診断部１６１は、受信信号の衝突タイプを‘第３衝突タイプ’、つまりリーダー対リーダー衝突タイプと診断するようにする。]
[0123] ＩＣＤモジュール１６２から出力されたリーダー衝突検出信号から‘ＩＣＤ＝ｐｏｓｉｔｉｖｅ’でない場合（Ｓ５３１）、‘Ｓ５３２’過程に進み‘ＶＢＤ＝ｐｏｓｉｔｉｖｅ’であるかを確認する。ＶＢＤモジュール１６３から出力された有効ビット検出信号から‘ＶＢＤ＝ｐｏｓｉｔｉｖｅ’であるものが確認されれば（Ｓ５３２）、衝突診断部１６１は、受信信号の衝突タイプを‘第２衝突タイプ’、つまりマルチリーダー対タグ衝突タイプと診断するようにする。一方、‘ＶＢＤ＝ｐｏｓｉｔｉｖｅ’でなければ（Ｓ５３２）、衝突診断部１６１は、受信信号の衝突タイプを‘第１衝突タイプ’、つまりタグ対タグ衝突タイプと診断するようにする。]
[0124] 図１４を参照すれば、衝突診断部１６１は、ＩＣＤモジュール１６２から出力されたリーダー衝突検出信号に基づいて‘ＩＣＤ＝ｐｏｓｉｔｉｖｅ’の場合（Ｓ５３１）、‘Ｓ５３３’過程に進み‘ＶＰＤ＝ｐｏｓｉｔｉｖｅ’であるかを確認する。‘ＶＰＤ＝ｐｏｓｉｔｉｖｅ’でないものが確認されれば、衝突診断部１６１は、受信信号の衝突タイプを‘第３衝突タイプ’、つまりリーダー対リーダー衝突タイプとで診断するようにする（Ｓ５３５）。] 図１４
[0125] ‘Ｓ５３３’過程で‘ＶＰＤ＝ｐｏｓｉｔｉｖｅ’の場合、衝突診断部１６１は、‘Ｓ５３４’過程に進みＣＲＣエラーが発生したかを確認する。ＣＲＣエラーが発生したことが確認された場合、衝突診断部１６１は、受信信号の衝突タイプを‘第３衝突タイプ’、つまりリーダー対リーダー衝突タイプと診断するようにする（Ｓ５３５）。この際、‘Ｓ５３４’過程でＣＲＣエラーが発生しないことが確認されれば、衝突診断部１６１は受信信号が正常タグ応答であると診断する（Ｓ５３６）。]
[0126] ‘Ｓ５３１’過程で‘ＩＣＤ＝ｐｏｓｉｔｉｖｅ’でないことが確認されれば、衝突診断部１６１は‘Ｓ５３７’過程に進み‘ＶＰＤ＝ｐｏｓｉｔｉｖｅ’であるかを確認する。‘ＶＰＤ＝ｐｏｓｉｔｉｖｅ’でない場合、衝突診断部１６１は‘Ｓ５３８’過程に進み‘ＶＢＤ＝ｐｏｓｉｔｉｖｅ’であるかを確認する。‘ＶＢＤ＝ｐｏｓｉｔｉｖｅ’の場合、衝突診断部１６１は、受信信号の衝突タイプを‘第１衝突タイプ’、つまりタグ対タグ衝突タイプと診断するようにする（Ｓ５４０）。一方、‘ＶＢＤ＝ｐｏｓｉｔｉｖｅ’でない場合、衝突診断部１６１は、受信信号の衝突タイプを‘第２衝突タイプ’、つまりマルチリーダー対タグ衝突タイプと診断するようにする（Ｓ５３９）。]
[0127] 一方、‘Ｓ５３７’過程で‘ＶＰＤ＝ｐｏｓｉｔｉｖｅ’であることが確認された場合、衝突診断部１６１は、‘Ｓ５４１’過程に進み‘ＶＢＤ＝ｐｏｓｉｔｉｖｅ’であるかを確認する。‘ＶＢＤ＝ｐｏｓｉｔｉｖｅ’の場合、衝突制御部１６１は‘Ｓ５４２’過程に進みＣＲＣエラー発生有無を確認する。ＣＲＣエラーが発生したことが確認された場合、衝突診断部１６１は、受信信号の衝突タイプを‘第１衝突タイプ’、つまりタグ対タグ衝突タイプと診断するようにする（Ｓ５４０）。この際、‘Ｓ５４２’過程でＣＲＣエラーが発生しないことが確認されれば、衝突診断部１６１は受信信号が正常タグ応答であると診断する（Ｓ５３６）。]
[0128] 一方、‘Ｓ５４１’過程で‘ＶＢＤ＝ｐｏｓｉｔｉｖｅ’でない場合、図１２の‘Ｓ５００’過程に進み前記‘Ｓ５００’〜‘Ｓ５７０’過程を再遂行するようにする。] 図１２
[0129] 次に、前述したことにより図４の衝突診断部１６１が衝突の発生有無を判断し、衝突が発生した場合、その衝突が本発明による３種衝突タイプの中でいずれに当たるかどうかを判断した後、その判断結果を受信した衝突解決部１６５が衝突を解決する方法について説明する。] 図４
[0130] まず、本発明によるメディアアクセス方法を簡単に説明すれば次のようである。ＲＦＩＤリーダーは、選択した周波数帯域の現在占有に関係なく準備（ｒｅａｄｙ）されればインベントリラウンドを開始することができる。すなわち、モバイルＲＦＩＤに分離されたチャネルが割り当てられない限りＬＢＴは必要でない。また、同一チャネル内で伝送するリーダーの間に同期化する必要がない。すなわち、特別な制御チャネルを確保しなくても本発明を適用することができる。適応型再伝送待機時間と結合して衝突状況に応じた命令再伝送を行うことが本発明の重要事項である。]
[0131] 図１５は本発明の実施例によって衝突解決部１６５が衝突状況別に命令を再伝送する手順を示すフローチャートである。図１５に示す手順は主に図４の状況別命令再伝送部１６５１によって遂行される。そして、衝突状況別に命令を再伝送するときに適用されるランダム待機時間を図４のランダム待機時間計算部１６５２が計算して状況別命令再伝送部１６５１に送信する。] 図１５ 図４
[0132] 衝突状況に応じた命令再伝送の基本内容を説明すれば次のようである。まず、マルチリーダー対タグ衝突またはリーダー対リーダー衝突が感知されれば命令が再伝送される。そして、リーダーは、衝突が感知された後に命令を再伝送するに先立ち、ランダム時間の間に遅延（ｓｕｓｐｅｎｄ）しなければならない。ＲＦＩＤリーダーで命令を伝送する間には衝突が感知されないので、命令の伝送が完了した後に衝突仲裁を開始することができる。すなわち、進行中の命令の伝送は中間にインターラプトされないと仮定する。]
[0133] また、リーダー側で、例えばＴ２タイムアウトのようなレシーバータイムアウト（Ｒｅｃｅｉｖｅｒ Ｔｉｍｅｏｕｔ）が感知されれば、命令が再伝送される。レシーバータイムアウトは、例えば有効なＲＦ変調、エンコード、またはメッセージ構造がないか、通信チャネル上に活動がなくてタグ状態マシンによってトリガーされるレシーバーアクティブ時間が終了することを意味する。レシーバータイムアウトがあればリーダーは命令を再伝送する。]
[0134] 本発明による衝突仲裁（ｃｏｌｌｉｓｉｏｎ ａｒｂｉｔｒａｔｉｏｎ）は命令を少なくとも一度再伝送することで具現化される。そして、損傷されたタグ応答が繰り返し受信されたら、複数回にかけて命令を再伝送することができる。後続の衝突可能性を減少させるために、衝突が感知された後、ランダム待機時間の間にリーダーを遅延させることで衝突回避が具現化できる。]
[0135] また、タグが現在の応答スロット（ｒｅｓｐｏｎｓｅ ｓｌｏｔ）ですでに分離（ｓｅｐａｒａｔｅ）された後、つまりタグＡＣＫ（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）とタグアクセス期間の間に、リーダーによって通信衝突が感知されれば、マルチリーダー対タグ衝突またはリーダー対リーダー衝突を解決するために関連命令が再伝送される。]
[0136] タグ衝突調整（ａｎｔｉ−ｃｏｌｌｉｓｉｏｎ、衝突防止）段階のうち、適切な手段によってリーダーがマルチリーダー対タグ衝突またはリーダー対リーダー衝突を決定することができない場合には、命令は再伝送されないであろう。すなわち、本発明の衝突診断部１６１のように通信衝突の３タイプを区分することができる衝突診断機能を備えていないリーダーは命令再伝送が禁止できる。その代わりに、同一通信スロットで応答する多数のタグによって発生するタグ対タグ衝突の場合を解決するための一般的なタグ衝突調整が適用される。]
[0137] 衝突後の再伝送試み回数には特に制限がなく、応用先によって適切に調整することが可能である。ついで、繰り返される通信トラフィック問題とその結果引き起こされる通信衝突を回避するためには、衝突が発生したとき失敗した再伝送試み回数の上限を設定することが好ましい。]
[0138] また、リーダーがレシーバータイムアウト（決められた時間内にタグ応答を受信することができない）を感知したら、一度だけ命令を再伝送する。レシーバータイムアウトの場合、命令を繰り返し再伝送しないというのは本発明において重要な点である。その代わりに、レシーバータイムアウトが持続する場合、一般的な衝突調整（ａｎｔｉ−ｃｏｌｌｉｓｉｏｎ）が適用される。例えば、マルチリーダー対タグ衝突から回復するために命令を再伝送（再発行、ｒｅｉｓｓｕｅ）する前に、リーダー領域内にあると予想されるまだ感知されないタグがある場合、スロットの数を減少させ、リーダーに応答するように許諾された少なくとも一つのタグが現在スロットにあることを確認する。]
[0139] また、関連のタグが命令を受けることができる場合にかぎり本発明による命令再伝送が意味あることを考慮しなければならない。タグが命令を受けやすい状態、例えばレシーバータイムアウトによって内部状態（ｉｎｔｅｒｎａｌ ｓｔａｔｅ）を変更しない場合に命令の再伝送が意味ある。ＩＳＯ／ＩＥＣ１８０００−６ Ｔｙｐｅ Ｃによって規定されたＵＨＦエアインターフェースの場合、Ｒｅｐｌｙ状態（ｓｔａｔｅ）またはＡｃｋｎｏｗｌｅｄｇｅｄ状態でＴ２タイムアウトがあれば、タグは仲裁（Ａｒｂｉｔｒａｔｅ）状態に転換される。この際、Ｔ２以上の待機時間後に命令を再伝送しても、タグ応答がないため、その効果を期待することができないものである。]
[0140] したがって、命令によって決まるタグの予想される内部状態がタイムアウトをもたらさないか、あるいは命令再伝送のために選択される待機時間がエアインターフェース仕様で規定されるタイムアウトの最小値より小さい場合に命令を再伝送する。リーダーがインベントリラウンドの早い段階でだけランダム待機時間の間に遅延することで、つまり一つ以上のタグがすでに分離されたら、それ以上ランダム待機時間の間に遅延しないという更なる制限を置くことで、このような潜在的な問題点を自動で予め解決することができる。]
[0141] 図１５に示されている、衝突解決部が衝突状況別に命令を再伝送する手順を概略的に示すフローチャートを参照して本発明による衝突状況別命令再伝送について具体的に説明する。] 図１５
[0142] まず、段階Ｓ１１００でリーダーが命令を伝送する。そして、リーダーは段階Ｓ１１０２で応答を受信する。もちろん、段階Ｓ１１０２は受信すべき応答がない場合や応答を受信することができない場合も含む。ついで、段階Ｓ１１０４に進み有効な（ｖａｌｉｄ）タグ応答がペンディング（ｐｅｎｄｉｎｇ）されているかどうかを判断する。有効なタグ応答がペンディングされているというのは、例えば、Ｑｕｅｒｙ、ＱｕｅｒｙＡｄｊｕｓｔ、ＱｕｅｒｙＲｅｐ命令の場合にはタグが現在スロットで応答しなければならない場合を意味し、この場合、有効なタグ応答がペンディングされていると判断する。段階Ｓ１１０４で判断した結果、有効なタグ応答がペンディングされていないと判断された場合、例えばタグ応答を受信しなくても良い場合には段階Ｓ１１０６に進む。段階Ｓ１１０４は他の方式が適用されることもでき、設計によって省略することもできる。]
[0143] 段階Ｓ１１０６ではリーダーが処理すべき命令がもっとあるかを判断する。処理すべき命令がもっとある場合には段階Ｓ１１０８に進み、次のリーダー命令を伝送し、段階Ｓ１１０２で応答を受信し、処理すべき命令がそれ以上ない場合には段階Ｓ１１１０に進みリーダーを中止する。]
[0144] 一方、段階Ｓ１１０４で有効なタグ応答がペンディングされていると判断した場合には、段階Ｓ１１１２に進む。段階Ｓ１１１２は本発明による衝突診断部によって衝突の発生有無及び衝突のタイプを決定する衝突感知（ｄｅｔｅｃｔ、診断）段階である。衝突診断部の判断結果、衝突がある場合には衝突の発生有無と決定された衝突のタイプを衝突解決部に伝送しながら段階Ｓ１１２２に進み、衝突診断部の判断結果、衝突がないと判断される場合には、衝突が発生しなかったという旨の信号を衝突解決部に伝送しながら段階Ｓ１１１４に進む。]
[0145] まず、段階Ｓ１１１２の判断結果、衝突が感知されない場合に進む段階Ｓ１１１４の後の手順を説明する。段階Ｓ１１１４では、レシーバータイムアウトであるか否かを判断する。判断結果、レシーバータイムアウトでない場合、段階Ｓ１１０６に進み次の命令を処理し、レシーバータイムアウトの場合、段階Ｓ１１１６に進む。]
[0146] 段階Ｓ１１１６ではタグがすでに分離（ｓｅｐａｒａｔｅ）されているかを判断する。タグが分離されたというのは、タグが現在の応答スロットに分離されていることを意味し、例えばタグＡＣＫとタグアクセス区間がこれにあたる。段階Ｓ１１１６での判断結果、タグがまだ分離されていないと判断された場合には、本発明による命令再伝送を実行せずに段階Ｓ１１２４に進み一般的なタグ衝突調整の手順を遂行する。すなわち、本発明によれば、まだインベントリラウンドの初期段階にあるリーダーの場合には、命令の再伝送を遂行しないことにより、他のリーダーが先にインベントリラウンドを完了することができる可能性を高める。]
[0147] 一方、段階Ｓ１１１６での判断結果、タグがすでに分離されたと判断された場合には、段階Ｓ１１１８に進む。段階Ｓ１１１８では、当該命令をすでに再伝送したかを判断する。段階Ｓ１１１８での判断結果、当該命令をすでに再伝送したと判断した場合には、段階Ｓ１１２４に進みタグ衝突調整の手順を遂行する。一方、段階Ｓ１１１８での判断結果、当該命令を再伝送したことがないと判断した場合には、段階Ｓ１１２０に進み当該命令を再伝送する。すなわち、リーダーがレシーバータイムアウトを感知し、タグがすでに分離されている場合、命令を一度だけ再伝送するようにする。これにより、レシーバータイムアウトの場合に命令を繰り返し再伝送しないようにし、一度の命令再伝送の後にもレシーバータイムアウトがある場合には一般的なタグ衝突調整を遂行する。]
[0148] 一方、段階Ｓ１１１２に帰り、段階Ｓ１１１２での判断結果、衝突があると判断された場合には、衝突解決部が衝突のタイプ（本発明による三つの衝突タイプの一つ）を受信し、段階Ｓ１１２２に進む。段階Ｓ１１２２では、衝突のタイプに基づいて、段階Ｓ１１２４に進みタグ衝突調整を遂行するか、段階Ｓ１１２６後に進み命令再伝送を遂行するかを決定する。衝突のタイプが‘タグ対タグ衝突’であれば、段階Ｓ１１２４に進みタグ衝突調整を遂行する。衝突のタイプが‘マルチリーダー対タグ衝突’または‘リーダー対リーダー衝突’の場合には、段階Ｓ１１２６の後の手順を遂行する。]
[0149] 衝突のタイプが‘マルチリーダー対タグ衝突’または‘リーダー対リーダー衝突’の場合、段階Ｓ１１２６では、再伝送回数が最大再伝送回数に到達したかを判断する。最大再伝送回数は設計によって決定された値であり、応用によって変えることができる。最大再伝送回数の制限を置くことで継続して再伝送が繰り返される状況を防止することができるが、この制限が必須なものではない。段階Ｓ１１２６での判断結果、最大再伝送回数に到達したと判断されれば、命令を再伝送せずに段階Ｓ１１２４に進みタグ衝突調整を遂行する。]
[0150] Ｓ１１２６での判断結果、最大再伝送回数に到達しなかったと判断されれば、手順は段階Ｓ１１２８に進む。段階Ｓ１１２８での判断結果、タグがすでに分離されたと判断されれば、段階Ｓ１１２０に進みリーダーを遅延させすに命令を再伝送し、タグがまだ分離されなかったと判断されれば、例えばインベントリラウンドの初期段階の場合、段階Ｓ１１３０に進みランダム待機時間を獲得し、獲得したランダム待機時間の分だけリーダーを遅延させる。]
[0151] 段階Ｓ１１３０では、図４のランダム待機時間計算部１６５２によってランダム待機時間を計算し、計算されたランダム待機時間を獲得し、獲得したランダム待機時間の分だけリーダーを遅延させる。ランダム待機時間計算部１６５２によって行われるランダム待機時間の計算方法については後に詳細に説明する。段階Ｓ１１３０の遂行によってランダム待機時間の分だけ遅延されたリーダーは段階Ｓ１１２０に進み命令を再伝送し、段階Ｓ１１０２に帰り応答を受信する。図１５を参照して説明した手順は例示的なもので、本発明の本質を逸脱しない範囲内で一部の変形及び省略が可能である。] 図１５ 図４
[0152] 図１６は図１５を参照して説明した衝突解決アルゴリズムの疑似コード表現（ｐｓｅｕｄｏ−ｃｏｄｅ ｎｏｔａｔｉｏｎ）で、Ｃ言語に使用される方式と類似に作成されたものである。本疑似コード表現はＩＳＯ／ＩＥＣ１８０００−６ Ｔｙｐｅ Ｃで決定したエアインターフェース仕様で規定されるモバイルＲＦＩＤリーダーの概念と用語を主に使用して作成された。提示されたコードは例示的な説明のためのものであり、本発明の範囲を制限するものではない。図１６は参照のためのもので、図１５に示された手順をコードで表現したものであるので詳細な説明は省略する。当業者であれば本発明の説明を参照して容易に理解することができるであろう。リーダーがいつも活性化されていると仮定したコードであり、ａｎｔｉｃｏｌｌｉｓｉｏｎ（）関数は従来のエアインターフェース仕様の衝突仲裁メカニズムを示すものである。もちろん、ａｎｔｉｃｏｌｌｉｓｉｏｎ（）を遂行するためには、例えばスロット数が１より大きくなければならないというなどのいくつかの前提條件をチェックすることにより、レシーバータイムアウトの場合にＱｕｅｒｙＡｄｊｕｓｔまたはＱｕｅｒｙＲｅｐのような更なるインベントリ命令を発行することが可能である。] 図１５ 図１６
[0153] 図１７〜図１９は本発明の実施例によって各衝突状況に応じた衝突解決方法を説明するための例示的なタイミング図である。通信衝突及びランダム待機時間選択を含むＩＳＯ／ＩＥＣ１８０００−６ Ｔｙｐｅ Ｃ命令及び応答シーケンスの一連の例示を示し、提示された例示はすべての可能なシナリオの中で選択された一部の例である。二つのリーダー（Ｒ１とＲ２）と一つのタグ（Ｔ）の間で衝突が発生する場合のランダム遅延時間適用を例として挙げている。] 図１７ 図１８ 図１９
[0154] 本発明では、モバイルＲＦＩＤ環境で同時に発生する命令伝送の欠点を解消するために、ランダム待機時間を導入し、これをＴＲとして表示する。二つの競争するＲＦＩＤリーダーが循環される（再）伝送試みを行って互いに邪魔する場合に発生する問題を避けるため、失敗したメッセージ伝送とその再伝送の間にランダム待機時間を適用する。図１５を参照して一部説明したが、ランダム待機時間を適用するための前提条件が満足される場合にだけランダム待機時間が適用される。] 図１５
[0155] また、現在衝突のタイプを正確に決定することができないか、リーダーに衝突診断機能が備えられていなければ、ランダム待機時間を適用するためのすべての前提条件が満足された状態で、タグ衝突調整の手順に指定された二つの連続したインベントリ命令の間、例えばＩＳＯ／ＩＥＣ１８０００−６ Ｔｙｐｅ Ｃの場合、ＱｕｅｒｙとＱｕｅｒｙＡｄｊｕｓｔの間に、ランダム待機時間を適用することもできる。]
[0156] まず、図１７はマルチリーダー対タグ衝突が発生した場合にランダム待機時間を適用するシーケンスを示す。リーダー（Ｒ１）はＳｅｌｅｃｔ命令とＱｕｅｒｙ命令を発行し、タグからＲｎ１６応答を受信した。リーダー（Ｒ１）は一つのタグをすでにシンギュレートし、リーダー（Ｒ２）は何のタグもシンギュレートすることができない状態である。そして、リーダー（Ｒ１）がＡＣＫ命令を伝送したが、同時に伝送されたリーダー（Ｒ２）のＳｅｌｅｃｔ命令と衝突が発生した。衝突が発生したとき、リーダー（Ｒ１）はすでにタグ（Ｔ）を分離した状態である。よって、リーダー（Ｒ１）はＩＳＯ／ＩＥＣ１８０００−６ Ｔｙｐｅ Ｃのタイミング規約によって最終命令（ＡＣＫ）を直ちに再伝送し、リーダー（Ｒ２）はランダム待機時間（ＴＲ）だけ遅延される。ここで、Ｔ３はリーダーが他の命令を発行する前、Ｔ１の後に待機する時間を意味する。] 図１７
[0157] 図１５の手順を参照して説明すれば、リーダー（Ｒ２）は段階Ｓ１１１２、Ｓ１１２２、Ｓ１１２６、Ｓ１１２８、Ｓ１１３０、Ｓ１１２０を順に遂行してランダム待機時間の間にリーダーを遅延させた後、命令を再伝送したものである。これにより、リーダー（Ｒ１）はＰＣ＋ＵＩＩ＋ＣＲＣ１６でなるタグ応答を成功的に受信することができることになり、マルチリーダー対タグ衝突が解決される。] 図１５
[0158] 次に、図１８はインベントリラウンドの初期段階で二つのリーダーが衝突するリーダー対リーダー衝突を示す。リーダー（Ｒ１）がＳｅｌｅｃｔ命令とＱｕｅｒｙ命令を発行した後、二つのタグがいずれもタグをシンギュレートすることができなかった状態で、タグ（Ｔ）の応答Ｒｎ１６とリーダー（Ｒ２）の命令Ｓｅｌｅｃｔ及びＱｕｅｒｙが衝突してリーダー対リーダー衝突が発生した。] 図１８
[0159] したがって、リーダー（Ｒ１）とリーダー（Ｒ２）はいずれもランダム待機時間（ＴＲ）の間に遅延され、リーダー（Ｒ１）は以後にＱｕｅｒｙＡｄｊｕｓｔ命令とＡＣＫ命令を伝送し、Ｒｎ１６とＰＣ＋ＵＩＩ＋ＣＲＣ１６の応答を成功的に受信することができることになり、リーダー対リーダー衝突が解決される。]
[0160] また、図１９はリーダー対リーダー衝突が発生したとき、リーダー（Ｒ１）がすでにタグを分離するほどに進行した場合に行われるシーケンスを示す。リーダー（Ｒ１）は一つのタグをすでにシンギュレートし、リーダー（Ｒ２）は何のタグもシンギュレートすることができない状態でリーダー対リーダー衝突が発生した。このような特別な場合、リーダー（Ｒ１）はＴ２の後にＡＣＫを再伝送し、リーダー（Ｒ２）はＴＲだけ遅延されることにより、リーダー対リーダー衝突が解決される。] 図１９
[0161] 次に、どの場合にランダム待機時間を適用するかについてさらに説明する。一般に、ＲＦＩＤリーダーは、セレクト、インベントリ、アクセスの三つの段階を持つ。現在のインベントリパス（ｐａｓｓ）で何のタグもまだアクノリッジ（ａｃｋｎｏｗｌｅｄｇｅ）されなく（タグがシンギュレート（ｓｉｎｇｕｌａｔｅ）され、ＡＣＫを伝送したが、応答を受信することができない）インベントリされなかったら、タグセレクト段階またはタグインベントリ段階で命令を再伝送する前、ランダム待機時間だけリーダーが遅延される。ここで、シンギュレーション（ｓｉｎｇｕｌａｔｉｏｎ）はタグのＵＩＩを読み取るために占有されなかった応答スロットでタグを強要（ｆｏｒｃｅ）することでタグを分離（ｓｅｐａｒａｔｉｏｎ）する手順を意味する。一方、リーダーはタグアクセスの間には遅延されない。]
[0162] ランダム待機時間はデフォルトとして適用されてはいなく、リーダーがインベントリラウンドの初期段階にある場合にだけ適用される。すなわち、タグをまだ分離しない場合にだけ適用される。そうでなければ、衝突する二つのリーダーは衝突後にいずれも自動的に遅延され、短い伝送ブレーキの後にほぼ並列的に続いて命令を発行することができることになり、これは衝突（後続の衝突）を再び発生させるであろう。その代わりに、二つのリーダーの中で一つだけがブロックされ、十分な時間だけ遅延されたら、その間に他のリーダーは最終命令を再伝送することができ、その間にすべてのインベントリラウンドを終了することができることになる。]
[0163] このような方法により、本発明による再伝送パターンが重畳する可能性を減らすことができ、より古い（ｏｌｄｅｒ）インベントリラウンドがより新規の（ｎｅｗｅｒ）インベントリラウンドより一般的に先に終了することができることになるので、公正な待機戦略を実施することができるようにする。]
[0164] 次に、本発明の実施例によって図４のランダム待機時間計算部１６５２がランダム待機時間を計算する手順について説明する。ランダム待機時間（ＴＲ）は性能を最大化させ後続衝突の可能性を最小化させることができるように選択されなければならない。したがって、平均的に良好な結果を達成するように、待機時間は最小再伝送待機時間（ＭｉｎＷａｉｔＴｉｍｅ）と最大再伝送待機時間（ＭａｘＷａｉｔＴｉｍｅ）に定義される範囲内でランダムに選択され、これがランダム待機時間として決定される。] 図４
[0165] ランダム待機時間はＦｍｉｎ（ＭｉｎＷａｉｔＴｉｍｅ）とＦｍａｘ（ＭａｘＷａｉｔＴｉｍｅ）に規定される基準値の間のランダム整数を選択することもでき、ＦｍｉｎとＦｍａｘによって与えられる値の間の時間値に応じたクロックサイクルの個数に応じた整数値を選択することもできる。]
[0166] 一方、プロトコルデータユニット（ＰＤＵ；Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）が重畳することができる時間を競争区間（ＣＰ；Ｃｏｎｔｅｎｔｉｏｎ Ｐｅｒｉｏｄ）と言う。プロトコルデータユニットはデータが伝送されるときの一定大きさのデータブロックを意味し、ＲＦＩＤリーダーまたはＲＦＩＤタグによって伝送されるすべての種類のデータパッケージで、リーダー命令及びタグ応答を含む。競争区間でリーダー命令またはタグ応答は脆弱であり、干渉によって破壊できる。タグインベントリの間に発行される典型的な命令シーケンスまたは単一プロトコルデータユニットの脆弱性を減少させるために、プロトコルデータユニットの持続時間（ｄｕｒａｔｉｏｎ）に比例してランダム待機時間を選択することが好ましい。]
[0167] まず、ランダム待機時間の下限（ｌｏｗｅｒ ｔｈｒｅｓｈｏｌｄ）である最小再伝送待機時間、つまりＭｉｎＷａｉｔＴｉｍｅ（Ｆｍｉｎ）は次の式によって計算される。]
[0168] ＭｉｎＷａｉｔＴｉｍｅ＝ｃ＊ｄｕｒａｔｉｏｎ（ｌｏｎｇｅｓｔＥｘｐｅｃｔｅｄＰＤＵ）
ここで、ｃは実際応用及び環境によって設定される定数値（動的（ｄｙｎａｍｉｃａｌｌｙ）に変更可能）であり、‘ｄｕｒａｔｉｏｎ’は選択されたリンク速度（ｌｉｎｋ ｒａｔｅ）でエアインターフェース上で一定のプロトコルデータユニットを伝送するのに必要な時間を返還する関数である。これからは、ｃを‘待機時間パラメーター’という。待機時間パラメーターｃは固定値であることもでき、動的に変更される値であることもできる。待機時間パラメーターｃを固定すれば静的な再伝送待機時間を演算することができることになり、例えばｃ＝１であることができる。ｌｏｎｇｅｓｔＥｘｐｅｃｔｅｄＰＤＵは‘予想最長プロトコルデータユニット’で、例えば図２０に示すＰＣ＋ＵＩＩ＋ＣＲＣ１６タグ応答である。] 図２０
[0169] このような方法でランダム待機時間の下限（最小再伝送待機時間）を決定するため、二つの競争するリーダー（Ｒ１とＲ２）が同一リンク速度を使用するし、計算されたランダム待機時間の下限が同一であれば、通信衝突によるそのインベントリ命令をＲ２がランダム遅延の後に再伝送する場合、同一プロトコルデータユニットによって後続衝突が発生しないというのを保証することができることになる。]
[0170] 図２０は本発明の実施例による最小再伝送待機時間の意味を説明するためのタイミング図である。図２０では、予想最長プロトコルデータユニットがＡＣＫ命令に対するタグ応答であると仮定した場合を説明する。ここで、リーダー（Ｒ１）はすでにタグ（Ｔ）を現在応答スロットにシンギュレートしたが、タグ応答と衝突するＱｕｅｒｙ命令を発行したリーダー（Ｒ２）によってリーダー（Ｒ１）がタグをアクノリッジすることに失敗した。一般に、タグが衝突するときに伝送を中断しないため、後続衝突を回避するためには、少なくともタグ（Ｔ）がＰＣ（Ｐｒｏｔｏｃｏｌ ｃｏｎｔｒｏｌ）、ＵＩＩ（Ｕｎｉｑｕｅ Ｉｔｅｍ Ｉｄｅｎｔｉｆｉｅｒ）、及びＣＲＣ１６（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ１６）でなるＡＣＫに対する応答を伝送するうちにはリーダー（Ｒ２）が遅延される必要があり、図２０はリーダー（Ｒ２）が最小再伝送待機時間だけ遅延されて命令を再伝送する場合を示している。リーダー（Ｒ１）によって発行される他の命令と後続衝突が依然として発生することができるが、最大再伝送待機時間を最小再伝送待機時間より非常に大きい値に設定すればこのような問題点を最小化させることができるであろう。] 図２０
[0171] 当該リーダーがどの命令をサポートするか（強制（ｍａｎｄａｔｏｒｙ）命令、オプション命令）によって、かつ実際応用（インベントリのみ、またはインベントリ＋タグアクセス）によって、予想最長プロトコルデータユニットはリーダー別に異なることができる。再伝送待機時間の上限または下限を計算するとき、リーダーは次のインベントリラウンドで送信または受信すべき最長プロトコルデータユニット及び使用するエアインターフェース仕様によってサポートされる最長強制命令をいつも参照することが好ましい。]
[0172] リターンリンク（タグ応答）で伝送されるプロトコルデータユニットに関し、例えばＱｕｅｒｙ命令を発行することでインベントリラウンドの間にリーダーが読み取るリターンリンク速度を、予想最長プロトコルデータユニットの決定のために使用することができる。例えば、ＵＩＩのバックスキャッターのように、受信すべきビット数を予め知ることができなくても、現在応用において可能な最大ビット数は予想することができる。これは、例えばエアインターフェース仕様がサポートするタグバックスキャッターの最大長さがもっと大きいとしても、現在応用がＵＩＩの長さを９６ビットまでサポートしたら、予想最長ＰＤＵを決定するのに９６ビットを超える値は使用しないこともできることを意味する。]
[0173] 次に、ランダム待機時間の上限（ｕｐｐｅｒ ｔｈｒｅｓｈｏｌｄ）である最大再伝送待機時間、つまりＭａｘＷａｉｔＴｉｍｅ（Ｆｍａｘ）は次の式によって計算される。]
[0174] ＭａｘＷａｉｔＴｉｍｅ＝ｃ＊ｄｕｒａｔｉｏｎ（Ｓｅｌｅｃｔ＋Ｔ４＋Ｑｕｅｒｙ＋Ｔ１＋ＲＮ１６＋Ｔ２＋ＡＣＫ＋Ｔ１＋ＵＩＩ）
ここで、ｃは最小再伝送待機時間の計算で使用された待機時間パラメーター、Ｔ１はリーダー伝送からタグ応答までの時間、Ｔ２はタグ応答からリーダー伝送までの時間であり、例えばＩＳＯ／ＩＥＣ１８０００−６仕様に規定された値による。前記式の例では、リーダーがＳｅｌｅｃｔ命令を伝送し、Ｔ４の時間の後にＱｕｅｒｙ命令を伝送し、タグがＴ１の時間の後にＲＮ１６を応答し、リーダーがＴ２の時間の後にＡＣＫ命令を伝送し、タグがＴ１の時間の後にＵＩＩを応答する。ＵＩＩは、前述したように、ＰＣ、ＵＩＩ、及びＣＲＣ１６を含む。]
[0175] 最大再伝送待機時間の式に使用されたｄｕｒａｔｉｏｎ関数によって返還される結果は次のインベントリラウンドでリーダーが使用するフォーワード及びリターンリンク速度及びＡＣＫ命令に対するタグ応答の予想長さによって変わる。最小再伝送待機時間について説明したものと同様に、タグによってバックスキャッターされるＵＩＩの長さを決定するために現在応用で可能な最大ビット数を予想して使用することができる。最大再伝送待機時間計算式に使用された‘Ｓｅｌｅｃｔ＋Ｔ４＋Ｑｕｅｒｙ＋Ｔ１＋ＲＮ１６＋Ｔ２＋ＡＣＫ＋Ｔ１＋ＵＩＩ’は例示的なもので、‘リーダー命令とタグ応答の総予想所要時間’に応じた値である。使用するエアインターフェース仕様及び応用によってこの値は変えることができる。タグアクセスが遂行されたら、関連した更なるリーダー命令とタグ応答を最大再伝送待機時間の計算に使用する。]
[0176] 図２１は本発明の実施例による最大再伝送待機時間の意味を説明するためのタイミング図である。図２１は予想されるセレクト及びインベントリ段階の長さが‘Ｓｅｌｅｃｔ＋Ｔ４＋Ｑｕｅｒｙ＋Ｔ１＋ＲＮ１６＋Ｔ２＋ＡＣＫ＋Ｔ１＋ＵＩＩ’によって決まると仮定した場合を説明する。最大再伝送待機時間の式によって決定された基準値がリーダー（Ｒ１）とリーダー（Ｒ２）の間の衝突を潜在的に解決することができるというのを示す。] 図２１
[0177] 図２２はＩＳＯ／ＩＥＣ１８０００−６ Ｔｙｐｅ Ｃ環境でのタイミングテーブルで、リンク速度と命令長さによってＭｉｎＷａｉｔＴｉｍｅとＭａｘＷａｉｔＴｉｍｅを計算する例を本タイミングテーブルを参照して説明する。最小再伝送待機時間及び最大再伝送待機時間は使用するリンク速度と伝送するプロトコルデータユニットによって決定される。テーブルでは、ｄａｔａ０（０２）に対してはＴａｒｉ＝２５μｓ、ｄａｔａ１（１２）に対しては１．５＊Ｔａｒｉのシンボル長さに基づいてフォーワードリンク速度を仮定するとき、すべての関連したプロトコルデータユニットのタイミングを列挙している。また、４０ｋｂｉｔ／ｓのＦＭ０エンコードされたデータがリターンリンクされると仮定した。これらの値は例示的なもので、使用するエアインターフェースによって変えることができる。] 図２２
[0178] 例えば、最小再伝送待機時間ＭｉｎＷａｉｔＴｉｍｅは、ｃ＊ｄｕｒａｔｉｏｎ（ｌｏｎｇｅｓｔＥｘｐｅｃｔｅｄＰＤＵ）＝ｃ＊ｄｕｒａｔｉｏｎ（ＵＩＩ）＝ｃ＊３３５０によって計算される。ｃが１の場合、最小再伝送待機時間は３３５０μｓである。また、最大再伝送待機時間ＭａｘＷａｉｔＴｉｍｅは、ｃ＊ｄｕｒａｔｉｏｎ（Ｓｅｌｅｃｔ＋Ｔ４＋Ｑｕｅｒｙ＋Ｔ１＋ＲＮ１６＋Ｔ２＋ＡＣＫ＋Ｔ１＋ＵＩＩ）＝ｃ＊（１３７５．０＋１２５．０＋９６２．５＋２５０．０＋５５０．０＋７５．０＋６６２．５＋２５０．０＋３３５０．０）＝ｃ＊７６００によって計算される。ｃが１の場合、最大再伝送待機時間は７６００μｓである。本例では、タグアクセス段階がないと仮定したものであり、タグアクセスが遂行されたら、関連した更なるリーダー命令とタグ応答を最小再伝送待機時間と最大再伝送待機時間を計算するのに使用することができる。]
[0179] 次に、本発明の実施例による適応型再伝送待機時間計算について説明する。前述した最小再伝送待機時間及び最大再伝送待機時間の式に使用された待機時間パラメーターｃ値を適応的に変更することで、実際応用での要求事項を最上に満足させ、実際応用シナリオによって性能と以後の衝突の間で最上のバランスを捜すため、待機時間パラメーターｃが再伝送待機基準値の下限と上限に掛けられることによってランダム待機時間をチューニングするのに使用する。ここで、‘再伝送待機基準値’は、前述した最小再伝送待機時間及び最大再伝送待機時間の式で、ｃに掛けられる値であり、最小再伝送待機時間において予想最長プロトコルデータユニットに必要な時間が再伝送待機基準値の下限、最大再伝送待機時間においてリーダー命令とタグ応答の総予想所要時間が再伝送待機基準値の上限である。]
[0180] 最小再伝送待機時間と最大再伝送待機時間の式に使用される待機時間パラメーターｃは、各インベントリラウンドの開始では１．０以上の値（ｃ＞＝１．０）を持つ初期値に設定でき、タグがリーダーによってアクノリッジされるまでは減少しない。これは、実際集団（ｐｏｐｕｌａｔｉｏｎ）の一つ以上のタグをすでにインベントリ及びアクセスしているかも知れない周辺のリーダーを保護し、当該リーダーによって発生する衝突可能性を減少させるのに好ましい。]
[0181] タグがリーダーによって成功的に感知された後には、追加の制限なしに残ったインベントリラウンド期間の間に待機時間パラメーターｃを変更することができる。すなわち、待機時間パラメーターｃは使用者の判断によっていつでも増加または減少できる。もし、待機時間パラメーターｃ値を固定したら、静的再伝送待機時間を演算することができる。]
[0182] この際、各インベントリラウンドの開始ではｃ値を制限することにより、再伝送待機時間に対する最初基準値を制限することは、チャネル利用に対する公正な手順を遂行するのに役立つ。タグ集団の中で一つ以上のタグをすでに感知しようとしているリーダーはそのインベントリラウンドを終了するために小さな待機時間を持つことになり、その間に活性化された新しいリーダーは最初ｃの値にあたるデフォルト設定を使用することになり、低いデューティーサイクルを持つことになる。]
[0183] エアインターフェース仕様によって使用者がリンク速度を規定することができるので、二つの競争するリーダーが互いに異なるリンク速度で動作することができる。この場合、リーダー（Ｒ１）とリーダー（Ｒ２）によって計算される最小及び最大再伝送待機時間の間に差があり得る。よって、再発する（ｒｅｃｕｒｒｅｎｔ）後続衝突の場合にパラメーターｃを調整することが必要である。反対に、観察される衝突の数がずっと小さく維持されたら、全体性能の向上のために同一パラメーターを使用することもできる。インベントリラウンドの間に待機時間パラメーターｃを変更する方法について以下に詳細に説明する。]
[0184] 図２３は待機時間パラメーターｃを現在衝突の比率によって動的に変更する手順を示すフローチャートである。待機時間パラメーターｃは最小再伝送待機時間及び最大再伝送待機時間の計算に使用されるパラメーターで、再伝送待機基準値（ｔｈｒｅｓｈｏｌｄ）に掛けられる値である。現在衝突の比率（ｃｏｌｌｉｓｉｏｎ ｐｅｒｃｅｎｔａｇｅ）は例えばリーダーの命令当たり衝突の平均回数である。] 図２３
[0185] 段階Ｓ１９００は新しいインベントリラウンドの開始を意味する。インベントリラウンドが始まれば、段階Ｓ１９０２で待機時間パラメーターｃを初期値に設定する。本例ではｃの初期値を１．０に設定する。この初期値は少なくとも一つのタグがアクノリッジされるまでは変更されない。]
[0186] 次に、段階Ｓ１９０４に進みタグがアクノリッジされたか否かを判断する。段階Ｓ１９０４での判断結果、タグがまだアクノリッジされなかったら、段階Ｓ１９０２に帰り、待機時間パラメーターｃを初期値に維持するかあるいは初期値にリセットする。段階Ｓ１９０４での判断結果、タグがアクノリッジされたら段階Ｓ１９０６に進む。段階Ｓ１９０６では、現在の衝突の比率（ｐｅｒｃｅｎｔａｇｅ）が衝突の比率基準値（ｔｈｒｅｓｈｏｌｄ）未満であるかを判断する。段階Ｓ１９０６での判断結果、現在の衝突の比率が衝突の比率基準値未満であれば、段階Ｓ１９０８に進み待機時間パラメーターｃ値をパラメーター変更ファクターｆだけ減少させる。すなわち、一番目のタグ感知（アクノリッジ）の後、衝突の比率が予め定義された基準値より低ければ、性能向上のためにファクターｆだけｃを減少させる。]
[0187] 段階Ｓ１９０６での判断結果、現在の衝突の比率が衝突の比率基準値未満でなければ、段階Ｓ１９１０に進み現在の衝突の比率が衝突の比率基準値を超えるかを判断する。衝突の比率が予め定義された基準値より高ければ、段階Ｓ１９１２に進みｃをファクターｆだけ増加させて平均再伝送待機時間を延長させることで、後続衝突の確率を減少させる。パラメーター変更ファクターｆの値は実際状況に応じて変えることができ、応用の必要に合うように選択されなければならない。一般に、パラメーター変更ファクターｆを０．１と１．０の間の値にすることができ、固定値でなく動的に変更される値にすることも可能である。]
[0188] 段階Ｓ１９１０での判断結果、衝突の比率が衝突の比率基準値を超えなければ（衝突の比率が基準値と同一であれば）ｃを変更せずに段階Ｓ１９０４に復帰する。本実施例で言及する衝突の比率基準値は実際応用シナリオによって変わる。例えば、バス停のように近くに位置するモバイルＲＦＩＤ使用者の数が大きいと予想される場合、基準値を大きく設定することができ、例えば家庭でＲＦＩＤを使用する場合のように使用者の数が小さいと予想される場合、基準値を小さく設定することができる。一般に、“衝突の比率（ｃｏｌｌｉｓｉｏｎ ｐｅｒｃｅｎｔａｇｅ）”という用語は干渉によって逃した、つまりリーダーが成功的に復号化することができなかったタグ応答の比率を示すと言える。]
[0189] 図２４は図２３の手順を確張したもので、待機時間パラメーターｃを現在衝突の比率及びタイムアウトの比率によって動的に変更する手順を示すフローチャートである。本実施例では、レシーバータイムアウトの比率（応答されなかった（ｕｎａｎｓｗｅｒｅｄ）リーダー命令の比率）を予定されたタイムアウトの比率基準値と結合して使用することを説明する。現在の衝突状況に応じて再発するレシーバータイムアウトがある場合、待機時間パラメーターｃを動的に増加させるかあるいはリセットする。] 図２３ 図２４
[0190] 図２４に示すすべての条件はリーダー側を参照している。例えば、段階Ｓ２００６の‘Ｃｏｌｌｉｓｉｏｎ Ｖｉｓｉｂｌｅ’（衝突が観察できるか）は受信したビットストリームを評価してリーダーで衝突を感知することができることを意味する。これはタグ側でだけ明かすことができるマルチリーダー対タグ衝突を含まないものである。さらに、リーダー側で現れるレシーバータイムアウトはいつも現在応答スロットにマッチングされるタグがないため発生するものではなく、隠されたマルチリーダー対タグ衝突を示すこともできることを考慮しなければならない。したがって、本実施例では、段階Ｓ２０１８の‘タイムアウトの比率が基準値を超えたか’の条件と段階Ｓ２０１２の‘衝突の比率が基準値を超えたかか’の条件が有機的に結合されている。] 図２４
[0191] ‘タイムアウトの比率（ｐｅｒｃｅｎｔａｇｅ）’は応答しなかったリーダー命令の比率を示す。例えば、リーダーが四つの命令を伝送し、そのうち二つに対してだけ（有効または無効の）応答を受信したら、タイムアウトの比率は０．５である。Ｓｅｌｅｃｔのようにタグ応答を要しない命令はタイムアウトの比率を計算するのに使用されない。タイムアウトの比率基準値は実際応用によって変わり、シナリオ別に変わることになる。]
[0192] 本実施例は、レシーバータイムアウトが観察されたとき衝突がすでにその頂点に到達していたら、レシーバータイムアウトによる再伝送が現在の衝突状況をそれ以上悪化させないことを保証する。また、現在のタイムアウトの比率がタイムアウトの比率基準値より低くなれば、待機時間パラメーターｃはプロトコル性能のためにその初期値に再びリセットされる。本実施例での用語‘衝突’はすべての形態の衝突を意味し、本発明による３種の衝突の間に何の差も発生させない。]
[0193] 図２４で、段階Ｓ２０００は新しいインベントリラウンドの開始を意味する。インベントリラウンドが始まれば、段階Ｓ２００２で待機時間パラメーターｃを初期値に設定する。本例では、ｃの初期値を１．０に設定する。この初期値は少なくとも一つのタグがアクノリッジされるまでは変更されない。] 図２４
[0194] 次に、段階Ｓ２００４に進みタグがアクノリッジされたかを判断する。段階Ｓ２００４での判断結果、タグがまだアクノリッジされなかったら、段階Ｓ２００２に復帰し、待機時間パラメーターｃを初期値に維持する。段階Ｓ２００４での判断結果、タグがアクノリッジされたら、段階Ｓ２００６に進む。段階Ｓ２００６では、衝突が観察可能（ｖｉｓｉｂｌｅ）であるかを判断する。すなわち、受信したビットストリームを評価し、リーダーで衝突を感知することができるかを判断する。衝突が観察可能であると判断されれば、段階Ｓ２００８に進み現在の衝突の比率が衝突の比率基準値未満であるかを判断する。段階Ｓ２００８での判断結果、現在の衝突の比率が衝突の比率基準値未満であれば、段階Ｓ２０１０に進み待機時間パラメーターｃ値をパラメーター変更ファクターｆだけ減少させる。]
[0195] 段階Ｓ２００８での判断結果、現在の衝突の比率が衝突の比率基準値未満でなければ、段階Ｓ２０１２に進み現在の衝突の比率が衝突の比率基準値を超えるかを判断する。衝突の比率が予定された基準値より高ければ、段階Ｓ２０１４に進みｃをファクターｆだけ位増加させ、平均再伝送待機時間を延長させることにより、後続衝突確率を減少させる。段階Ｓ２０１２での判断結果、衝突の比率が衝突の比率基準値を超えなかったら（衝突の比率が基準値と同一であれば）ｃを変更せずに段階Ｓ２００６に復帰する。]
[0196] 一方、段階Ｓ２００６での判断結果、衝突が観察可能でない判断された場合、段階Ｓ２０１６に進みタイムアウトが観察可能であるかを判断する。タイムアウトが観察可能でない場合には、段階Ｓ２００２に進みｃを初期値にリセットするが、タイムアウトが観察可能である場合には、段階Ｓ２０１８に進み、タイムアウトの比率が予定されたタイムアウトの比率基準値を超えたかを判断する。段階Ｓ２０１８で、タイムアウトの比率が基準値以下であると判断されれば、段階Ｓ２００２に復帰するが、タイムアウトの比率が基準値を超えたと判断されれば、段階Ｓ２０１２に進み衝突の比率と基準値を比較する。このような手順をインベントリラウンドごとに繰り返し行うことにより、再伝送待機時間を適応的に変更設定することができることになる。]
[0197] 前述した本発明のモバイルＲＦＩＤリーダーに関するエアインターフェース仕様は、静的（ｓｔａｔｉｃ）ＲＦＩＤリーダーに使用するために開発された従来のエアインターフェース仕様に結合されて適用することもできる。本発明は、前述したような諸実施例の構成と方法に限定的に適用可能なものではなく、諸実施例は、多様な変形ができるように各実施例の全部または一部が選択的に組み合せられて構成することもできる。]
[0198] 本発明はモバイルＲＦＩＤシステムに使用されることにより、衝突の可能性を減少させ、衝突が発生したとき、衝突の発生原因を把握し、その原因及び様相によって適応的に衝突を解決することができるので、モバイルＲＦＩＤの底辺拡大に大きく寄与するであろう。]

权利要求:

請求項1
衝突状況に応じて命令を再伝送するＲＦＩＤリーダー装置であって、一つ以上のタグに対して信号を送受信することが可能なＲＦ通信部からの送信信号に応じて、所定の受信時間の間に受信された受信信号のデータを分析し、前記受信信号の衝突発生の有無を確認し、受信信号データの分析結果に基づいて衝突タイプを診断する衝突診断部；及び前記衝突診断部から受信した衝突発生の有無及び衝突タイプに基づいて、衝突状況に応じてタグにＲＦ通信部を介して命令を再伝送できるようにする衝突解決部を含んでなり、前記衝突解決部は、衝突発生の有無と衝突タイプに基づいて命令を再伝送するか否かを判断する状況別命令再伝送部、及び命令の再伝送のためのランダム待機時間を計算するランダム待機時間計算部を含むことを特徴とする、ＲＦＩＤリーダー装置。
請求項2
前記衝突診断部が診断する衝突タイプは、タグ対タグ衝突、マルチリーダー対タグ衝突、及びリーダー対リーダー衝突を含むことを特徴とする、請求項１に記載のＲＦＩＤリーダー装置。
請求項3
前記衝突解決部は、受信した衝突タイプがマルチリーダー対タグ衝突またはリーダー対リーダー衝突の場合、命令を再伝送することを特徴とする、請求項１に記載のＲＦＩＤリーダー装置。
請求項4
前記衝突解決部は、タグが分離されていないと判断した場合、前記ランダム待機時間計算部が計算したランダム待機時間だけ遅延した後に命令を再伝送することを特徴とする、請求項３に記載のＲＦＩＤリーダー装置。
請求項5
前記衝突解決部は、タグが現在の応答スロットに分離されていると判断した場合、ランダム待機時間だけ遅延せずに命令を再伝送することを特徴とする、請求項３に記載のＲＦＩＤリーダー装置。
請求項6
前記衝突解決部は、最大再伝送回数に到達したと判断した場合、命令を再伝送せずにタグ衝突調整（ａｎｔｉ−ｃｏｌｌｉｓｉｏｎ）を遂行するようにすることを特徴とする、請求項３に記載のＲＦＩＤリーダー装置。
請求項7
前記衝突解決部は、レシーバータイムアウトが発生した場合、命令を再伝送することを特徴とする、請求項１に記載のＲＦＩＤリーダー装置。
請求項8
前記衝突解決部は、レシーバータイムアウトが発生し、タグが現在の応答スロットに分離されていると判断される場合、命令を再伝送することを特徴とする、請求項７に記載のＲＦＩＤリーダー装置。
請求項9
前記衝突解決部は、レシーバータイムアウトが発生した場合、命令を一度だけ再伝送することを特徴とする、請求項７に記載のＲＦＩＤリーダー装置。
請求項10
命令伝送の後、所定時間内にタグ応答を受信することができない場合、レシーバータイムアウトが発生したと判断することを特徴とする、請求項７に記載のＲＦＩＤリーダー装置。
請求項11
衝突診断部及び衝突解決部を含み、衝突状況に応じて命令を再伝送するＲＦＩＤリーダー装置の制御方法であって、前記衝突診断部が、ＲＦ通信部からの送信信号に応じて、所定の受信時間の間に受信された受信信号のデータを分析し、前記受信信号の衝突発生の有無を確認し、受信信号データの分析結果に基づいて衝突タイプを診断する衝突診断段階；及び前記衝突解決部が、衝突発生の有無と衝突タイプに基づいて、衝突状況に応じてタグにＲＦ通信部を介して命令を再伝送できるようにする衝突解決段階を含んでなり、前記衝突解決段階は、衝突発生の有無と衝突タイプに基づいて命令を再伝送するか否かを判断する状況別命令再伝送段階、及び命令の再伝送のためのランダム待機時間を計算するランダム待機時間計算段階を含むことを特徴とする、ＲＦＩＤリーダー装置の制御方法。
請求項12
前記衝突診断段階で診断する衝突タイプは、タグ対タグ衝突、マルチリーダー対タグ衝突、及びリーダー対リーダー衝突を含むことを特徴とする、請求項１１に記載のＲＦＩＤリーダー装置の制御方法。
請求項13
前記衝突解決段階において、衝突タイプがマルチリーダー対タグ衝突またはリーダー対リーダー衝突の場合、命令を再伝送することを特徴とする、請求項１１に記載のＲＦＩＤリーダー装置の制御方法。
請求項14
前記衝突解決段階において、タグが分離されていないと判断した場合、前記ランダム待機時間計算部が計算したランダム待機時間だけ遅延した後に命令を再伝送することを特徴とする、請求項１３に記載のＲＦＩＤリーダー装置の制御方法。
請求項15
前記衝突解決段階において、タグが現在の応答スロットに分離されていると判断した場合、ランダム待機時間だけ遅延せずに命令を再伝送することを特徴とする、請求項１３に記載のＲＦＩＤリーダー装置の制御方法。
請求項16
前記衝突解決段階において、最大再伝送回数に到達したと判断した場合、命令を再伝送せずにタグ衝突調整（ａｎｔｉ−ｃｏｌｌｉｓｉｏｎ）段階を遂行するようにすることを特徴とする、請求項１３に記載のＲＦＩＤリーダー装置の制御方法。
請求項17
前記衝突解決段階において、レシーバータイムアウトが発生した場合、命令を再伝送することを特徴とする、請求項１１に記載のＲＦＩＤリーダー装置の制御方法。
請求項18
前記衝突解決段階において、レシーバータイムアウトが発生し、タグが現在の応答スロットに分離されていると判断される場合、命令を再伝送することを特徴とする、請求項１７に記載のＲＦＩＤリーダー装置の制御方法。
請求項19
前記衝突解決段階において、レシーバータイムアウトが発生した場合、命令を一度だけ再伝送することを特徴とする、請求項１７に記載のＲＦＩＤリーダー装置の制御方法。
請求項20
命令伝送の後、所定時間内にタグ応答を受信することができない場合、レシーバータイムアウトが発生したと判断することを特徴とする、請求項１７に記載のＲＦＩＤリーダー装置の制御方法。